It's interesting to see Sega finally catching up to the connectivity available with competitors like the Atari 2600 (via Gameline).
Now all they need is a game as fun and addicting as Kaboom! to download.;)
Re:Damn lies and statistics...
on
Silicon Hell
·
· Score: 2
Huh? A code violation is a code violation - being big doesn't give you an excuse to make more of them. Rather, it makes you more responsible to avoid making them, because the effect is magnified when you do.
If it were "accidents" or even "fires" I'd agree with you, but that's not what we're talking about here. Violating some code occurs because the company chose to do things that way. It's not a question of scale, but of policy.
Uh, this reads like spin control from a company that finds itself in dire need of some. Skip ahead in the article to the part starting with
Applied Materials - the world's largest manufacturer of semiconductor-making equipment - may rank number one in the valley for fire and safety code violations.
>Clean rooms are "cleaner than hospital rooms," Oswalt said. "I'd rather live there than be on the street."
What the hell kind of meaningless statement is that? Even for a corporate spokesthingy this is idiotic. Not that I wouldn't like to see it happen; kind of like the Chinese officials responsible for airline Y2K readiness (the sky is falling, indeed). Too bad that really was a chicken little story, but this isn't.
The whole consumer electronics industry (including and especially computers) has always rested on inexpensively poisoning people too poor to have a choice in the matter. It's amusing to watch the/. posters' denial of that idea; tough to reconcile while you use your $1500 computer to read the article, isn't it? Did you really think $1500 could buy any sort of environmental control and worker protection? Somebody had to pay for that stuff you're using, and it sure wasn't you.
It's possible to do quite a bit with the native speech recognition stuff that's built into the classic Mac OS, especially combined with Applescript - even though Apple has never had much clue what to do with this stuff, you can. The speech recognition itself is explicitly designed for command control, not dictation. That means it works very well for controlling apps and the OS, but not at all for entering the content of an email, say. Possibly you could combine it with something like that IBM continuous-speech software and address both needs. Discrete command recognition is just what you need for controlling X10-style remote devices, though, and there is a company that makes that ADB control & sensing equipment for Macs as well as an interface to home X10 systems. They'd probably be able to give you an idea of how much physical home control you could do from Applescript (and thus speech) control, too. Any cheap old pre-G3 Powermac will handle this stuff fine (especially since they have ADB), so you may be able to experiment with at least the speech part for free if you have access to one.
The main problem with this idea is that you're probably looking at combining a number of different technologies in addition to speech commands and X10, and there are more of those in total for Windows (ironic because Windows is inherently harder to control and use than just about anything else). And despite X10's recent nauseating push to quasi-porn spycam marketing, they have been doing home control for decades (I remember seeing an entire house controlled from an Apple ][ at an exhibition once).
One of the neatest command speech apps I've seen was an integrated solution for Mac Netscape (Speech Navigator?) that allowed one to say "Navigator Back", "Navigator Scroll Down", "Open link 'Access Technologies'", etc. It worked amazingly well, but some pages were more accessible than others (the Slashdot main page would suck, for instance, since all the important links have the same name - "Read More..."). Nowadays you could probably write custom scripts to do the same thing with a more scriptable browser, like iCab or IE5.
I've read before that this was indeed the reason for the events in Mostly Harmless - DNA was sick of it all and just wanted to get on with other things. If this question is posed him, I'd be interested to know whether he now regrets having written it in that way and from that frame of mind, or whether it did exactly what it was intended to and he remains glad of it.
Interesting - I too had the crap scared out of me by Doctor Who at an early age (much younger than eight or nine, though). For me it was the Daleks; apparently I'd dive behind the couch every time they threatened the Doctor's extermination. I also had the crap rescared out of me later on by riding in the coin-operated talking Dalek at the Bull Run in Birmingham or London ('cause I was a big boy and wouldn't be scared, promise).
I think the real reason DNA required convincing to allow the release of Shada was that it's just not a very good episode. The incompleteness doesn't help either; it's almost comical to see Tom Baker come out between scenes and say "I managed to escape, but then..."
>The right way to handle this is to tell them that they can either >release the module under the GPL, immediately, or go to court.
I agree, because the intention of using the GPL has always been to make more code open - the "virus-like" nature that some people condemn is, nonetheless, the point. Companies and authors rigorously defend other copyrighted material every day for their own motives of financial gain or creative control, and legally the GPL is nothing more or less than a copyright. Having them remove the offending code is not the motive for initially using the GPL - opening up the derivative code is.
Removing the code and replacing it with a functional equivalent doesn't even really address what they've already gained from it, either, because it was there during the development effort and its presence will have been partly responsible for the final state of the other, closed code in the project. In other words, not all the damage can be undone (but note that this point isn't likely to be addressed by copyright law - in fact the idea is more akin to patents).
However, since not everyone does have your resources, there need to be legal funds in place to deal with these cases.
I agree with your argument here (that designed languages aren't on the same level as natural ones), but your example is weird. How is C an evolved language? It's just as designed as Pascal is (in fact it was designed on two occasions, to its considerable detriment the second time). The two languages just have considerably different design goals.
Perhaps you're suggesting that the ANSI committee played a role analogous to the Academie de la Langue Francaise? The problem is that the analogy is too unbalanced - computer languages are completely trival when weighed against computer languages. They also have rather opposite goals; C and Pascal are designed to clarify and limit the range of expression (assuming one agrees that programming can be expressive, which I do - but then I'm a coder), while natural languages largely try to broaden it. Look at a word like "aimer" in French; it's codified by l'Academie, but the vagueness of its meaning is intentional, and in fact integral. Natural languages are full of stuff like that - right now there are a bunch of old men on the island of Java speaking the formal male language and trying to trip each other up with that kind of nuance for their version of karma points.;) The computer version of Java certainly has its ambiguity, but the intention was always to design it out.
It's just a bit trite to state that people use language to communicate, because you haven't defined (and really can't define) what communication is or is for. In fact it's for so many different things that attempting to define the "problem space" is almost arrogant, and certainly doomed (see my other long-winded posting at the root of this thread). I think this again goes back to the lack of real analogy between computer and human language; computer languages do have (and exist because of) a finite problem space, but people talk doesn't.
I do agree with the idea that our children's children will be speaking a pastiche of languages, though. I just hope that there's more than one pastiche left around, not a monoglot.
The idea of limiting the scope of human expression in the name of easier commerce is one of the most frightening aspects of the free-market agenda.
Language isn't merely a means of communicating ideas, it helps define the range of what you can and can't consider. Language isn't thought, but it crystallises thought (and that one's not mine, I paraphrase Samuel R. Delany). If thought is the probabilistic wave function, language is what lets it collapse into a finite meaning and nuance and emotion that you can express to another human (that one's mine). But when you collapse a wave function into a particular state, you irretrievably lose an infinite number of other possible states. Killing off the hundreds of non-English languages on this planet will cut us off from things that we simply can't imagine (precisely because we'll never again have the words to express them).
I used to be bilingual in French and English, though in recent years I've lost the sexier of those two languages for the more technical (how dumb am I). At one time I could think in two languages, and I was often struck by the fact that I had different thoughts available to me depending on which one I was in, and even more resulting from the play between the two. If you've never taken the time to learn another language (and by that I mean the only way that really works, by moving somewhere where people will talk to you in it exclusively until you think it when you wake up in the morning), you can't imagine how much it can enrich your experience and insight, and I can't recommend it highly enough ( for which I blame the limitations of language;).
A weak example of the sort of thing I'm blathering about is the different perspective that some native North and especially South American people have about the nature and passage of time. Hopi people are (somewhat but not entirely apocryphally) credited with an picture of time as a sort of frozen landscape, for instance. It is possible to get that sort of insight from a European speaker's perspective (peyote helps, just ask Carlos Castaneda), but it's a lot harder. If you could learn Hopi from a native speaker, it might make a lot more sense. Maybe you'd go on to build an FTL drive, who knows? One might argue that it's only a common *additional* language that's under discussion, but history has shown that pressing for one dominant language will slowly kill off the others (to seriously argue otherwise now seems naive, not to mention insulting to those cultures we've already killed off 'round here). The point is that that's about as smart as extinguishing all those possible cancer cures in the rain forest. You just never know what you're losing.
>In fact, any rational person would expect these peoples' correlational study to turn out as it >did...not because video games cause violence but because violent personalities are probably more >inclined to play violent video games. Which would take all responsibility for this violence off of >the video games' shoulders.
I think you've misinterpreted both the original results and the critique. The initial aggressiveness of the subjects was controlled for in the experiment; basically, everyone got a go. I do believe there were confounding factors in the noise-blast portion of the experiment (which the critique gets close to discovering - for instance I'd be more concerned about the fact that Wolf 3D is more adrenalising than Myst (even though it bores the heck out of me), and thus likely to make people less sensitive to any kind of critical choice, noise-blast-duration or anything else). Between-subject difference wasn't one of them, however; this is one of the most basic elements of research design, and no psych journal would publish a study that was so easily confounded in that manner.
Like the author of the critique, I'm a tech type with a lot of video game experience and a psych degree (convincingly named a B.S.S.;). I agree with much of what he was getting at, but he draws no real conclusion other than "think carefully over the implications of research results". What some readers may be missing is that this is a basic credo in interpreting *any* sort of research in the social sciences (not that they can be blamed for that - the mass media sure doesn't get it). Of course correlation doesn't imply causation, but it certainly doesn't argue against it. Even the tired old ice cream example is flawed; how do you know that summertime sugar rushes don't combine with heat to induce aggression? You can't say it doesn't any more than you can say it does.
Common sense is often the best tool we have in this sort of area. Does playing a little Quake or Marathon turn you into a monster? Nope, but playing a hell of a lot of it really will tune you out of reality and skew your idea of what's reasonable to do IRL. Been there, done that (but it was MUDs and not 3D shooters, coincidentally while I was supposedly taking that psych degree). The real danger of twitch games isn't as much the violent content as the addictiveness; the violence just isn't a great ingredient in the kind of mild dissociation that results from doing anything out of balance. Any kind of science requires a healthy amount of agnosticism, and the thing you have to be most agnostic about is the value of Science itself.
There's one other thing I've noticed about mouse and keyboard use that might bear mentioning. Any physical device but the most tank-like will wear out more quickly if you use it harder, and most people click and hold buttons and hit keys much harder than they need to. One reason my old ADB mouse lasted so long was probably the fact that I almost obsessively try to use a light touch wherever possible. The nicest thing about doing this is that you'll also be preserving the other, more important parts of the mechanical input system - your fingers and wrists. If your mice wear out consistently more often than other people's, you might want to ask someone to watch you compute and see whether you're unintentionally being a little harder on yourself and your equipment than you need to be.
Manufacturing quality and cost still makes a difference, though; the last University lab I administered had 10 (pre-USB) Macs and 10 PCs, and it was only the PC mice (M$) that had problems. The Macs were more heavily used, too (I'll leave aside questions of whether GUI design inconsistency and unreliability increases people's stress and causes people to press more anxiously on the Wintel mice, though it probably does). In fact they were constantly used, twelve hours a day. And there's the obvious corollary that a higher quality button will probably respond more consistently in the first place, making it less likely to create hard-clickin' habits.
Anyway, that's enough out of me for this thread. Wonder why this subject wasn't deemed interesting enough for the main page?
FreeBSD "non-async" mounts differ a bit from Linux's idea of "sync". Linux's async is completely async, as in it writes data and metadata willy-nilly as the opportunity arises. Its sync mount is just the opposite, writing everything synchronously in an anal-retentive manner that's just too slow for most real-world use. FreeBSD's async mount is the same (dangerous), but the default mount is actually "non-async" which offers a sort of best-of-both compromise where metadata is written synchronously (you can also make a UFS filesystem completely synchronous, with roughly the same performance penalty as on Linux).
Softupdates is very cool, but it's not really journalling AFAIK. It's just a very well-thought out extension to the existing FFS "non-async" mode that knows how to ordering metadata writes so that a crash can always be recovered from, and so that it knows which ones it can be lazy about. Thus both performance and reliability are improved, and it accomplishes one of (not all) of the goals of a JFS, but in a fairly different manner. There are still benefits to be had from adopting a real JFS, though (I'm pulling for SGI's XFS). I understand softupdates is also due to be released fully free under the BSD licence, once the author thinks it's ready (it's part of the distribution now, you just have to create the symlinks in indication of your acceptance of the current licence). There's a white paper on softupdates at http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ that gives some explanation of the existing sync/non-async/async scheme as well.
I think this is simply a consequence of the poor manufacturing quality of the mice that you and most other people have used. I've never found those Sun mice or keyboards (any revision) to be worth squat, and Logitech isn't exactly the Cadillac of consumer devices either - they're just another company that sells mass quantities of low-margin plastic stuff as cheaply as possible. If you want good input/output equipment, you've always had to pay for it. Though it's only useful as an example (not for X, given the single button), Apple's older one-button mice and notebook trackballs were built to last - the ADB Mouse I that came with my Apple IIgs is still going strong after 14 years (about half of them very heavy-use) and countless thousands (millions?) of clicks. Likewise, I used a Powerbook Duo for at least five years without a problem, and it was bought used. Both of those used the same tried-and-true microswitch for the clicker, actually (made in the United States for whatever that's worth - nowadays they're from Malaysia, which coincidentally means the people who made them probably got paid crap to boot). I also had a decent mouse on an SGI Indy2 once, but then the computer cost $50k (and SGI has sold junk too).
Contrast to Apple's current offering, which besides the love-it-or-hate-it design just isn't any better quality than any other random PC crap, Microsoft, Logitech, or whomever - expect all these things to break, and quickly. The leaf-switch trackpad button on my last Powerbook (2400), which was built by IBM and sold by Apple, wore out after four months. (Then again, the whole notebook died a year after that, and then again another seven months after having the dead motherboard replaced at my cost. Bye, Apple (and by implication, IBM)).
There are better devices out there, but you won't find them at your local megamart. I've never heard anything bad about a Contour mouse, for instance; besides the fact that they have an actual ergonomic design (no hockey pucks or shiny tail-lights here), you can get them sized to your hand, and even right or left handed as appropriate. The same applies to keyboards (the best ones going are made by Kinesis, and they're totally worth the one-time cost). Now that there's a reasonable cross-platform attachment standard that probably won't disappear for a while (USB), it seems particularly worthwhile to spring for some really high quality, lasting input devices that you can take with you from upgrade to upgrade.
In other words, the x86 PC accessory industry you've grown up with is a poor horizon. There's just no doubt that all of the mass-market stuff out there is complete crap (especially anything that comes with the computer system when you buy it). Look to the people trying to provide small-volume ergonomic devices, and chances are you'll find something that's built to last as a bonus.
I interpreted that rule in this way too, but now I suspect they were intended differently. I think that rather than the semantic interpretation of a site that would "link" via an HTML anchor, the author probably had the broader concept of "to link to" in mind, as in the English verb. It's a bit ambiguous, but...
...Of course one could argue that the reader's interpretation of "link to" is an integral part of their next-URL choice, and thus of the interactivity (which is otherwise sparse IMHO), in which case the rules work just the way they're supposed to.
As for whether it should have no rules at all, what would be the point? It'd just be a random URL submission page, and there are more than enough of those, thanks.
>Now, the Church clearly doesn't have a legal leg to stand on to prevent sales (and if they sell it >anyway, why would they, I mean, the resale market through E-bay won't really effect their bottom >line to the extent legal fees will), but they can probably protect certain terms.
I expect the CoS's legal fees are nil; all their lawyers would be scientologists (it's a natural fit, after all, you can apply your skills of harassment and irritating bafflegab in two directions at once!).
Interesting document; I've never bothered to read it before (mostly because X/Open is pretty irrelevant these days). According to that, just about anything is an abuse of the trademark, including your *Nix (they cite UN*X, but it would presumably apply). In fact they'd much prefer that you never, ever say anything about Unix (my preferred spelling) without fully stating your terms, as in "UNIX® Operating System", which is perhaps admirably accurate, but doesn't lend itself much to conciseness (ironically enough for an OS with mostly two-letter commands).
The paper taken as a whole is actually pretty absurd; it just goes too far. Even if the trademark weren't diluted all to hell, we're basically talking about four letters; how many slightly similar variations can they reasonably expect to control?
In any event, I don't think the original poster was commenting on the names of the systems at all; s/he was pointing out that software that conforms to the Linux API generally conforms to the Unix API (sorry, I meant the UNIX® Operating System's Application Programming Interface). In other words, that it would be nice if people who've adopted and started coding for Linux would discover that they're actually coding for a much broader audience (with very little extra effort, or none). Which is actually the source of the whole UNIX trademark dilution problem in the first place.
>The spooky part is that the corresponding random bit on the other end changes instantaneously.
Yup, it was to this which I referred. The FTL-communication part is simply what you state: that particle a "knows" some element of state about particle b instaneously, regardless of the distance seperating them. Constructing a thought experiment where FTL communication appears to occur does depend on the definition of "communication", of course, and that term is pretty overloaded in this thread because the original article is about a encrypted digital human communication system (which obviously works at sublight speed). It seems to me that this system is all about modulating the higher-level communication (ie. the venus idol picture) with the lower one (the correspondent particle states).
I'll see if I can dig up the original reference somewhere; it was a lot more persuasive than I'm being.:)
It is possible to think up circumstances where particle "entanglement" creates the paradox of FTL communication (between the particles, and anything which resolves their state). Though paradox may not be quite the right term, since in many ways the lightspeed limit has nothing to do with quantum mechanics, and entanglement is AFAIK a purely quantum mechanical notion (I recall an article a few years ago in some lay science rag discussing how the c limit is more like a choice Einstein made to make a relativity model possible, and how he pretty much rejected quantum theory wholesale, albeit for more philosophical reasons).
>The task itself imposes the minimum level of complexity. >Bad user interface can increase the complexity that the user has to deal with, >but even the best user interface can never decrease complexity below what the task demands.
I find this an extremely insightful point (if I had any moderation points at the moment I'd say so in a different manner), but I'd note that it's not the complexity of the task per se that's the issue, but the number and type of options available to the user.
That is, we tend to be inundated by choice, and a good UI tries to minimise the choices in order to keep them manageable. In fact, I suspect that intentional channeling of effort on the part of GUI designers is why a lot of self-proclaimed old school types fear and shy away from GUIs (especially ones that really try to make this point work, like the Mac) - it feels like choice being taken away, because it is (I should note that I find such a reaction naive, because the choice was necessarily similarly limited in whatever UI the neo-neo-luddite previously preferred, a CLI for instance - it's just less visually obvious and perhaps actually more insidious because of that). It's not just the choices the user that need to be managed, but the choices a developer might make (for instance in presenting the user's choices in some nifty neato way). But then we get onto the teeter-totter of consistency vs. creativity, and I'm not playing there today.;)
The point about making things appear too simple - which I'll recast as obscuring choice that the user or some subset of users really needed to be aware of - is well taken, though, and may be part of a larger point where the user needs to be aware of the simple fact *that* other choices have been obscured in the name of ease-of-use, a sort of meta-UI design.
Actually, I hate LILO. I'm (genuinely) curious what the people posting in its favour like about it - it seems to me that it's not so much the favourite as it is the sole viable option, currently. In particular, have they used other schemes, like FreeBSD 3-4's multi-stage bootloader? A real CLI that can actually do stuff like read a filesystem, name a kernel by sight, and dynamically switch devices even from the first-stage loader in the boot block (not to mention from either a serial line or a console, automatically probed for or manually switchable at boot time). The next stage loader after that can dynamically preload modules, among a host of other useful features. And I don't have to update the MBR on the raw disk (!) every damn time I rebuild a kernel.
LILO has been due for replacement for a looong time, and it should probably take the current reliance on the awful MS-DOS fdisk style partitioning scheme with it (for a slice scheme like the BSD and many others use, or better still a completely flexible named-partition design like the (gasp) Mac has had for years). Really, these are areas that have been addressed by other Unices for years, including the free ones.
I've long thought that the Unix kernel is a perfectly good choice for PDAs - in fact it's one of the reasons microkernels are a good idea, since one can use a scaled-down Unix "server". Linux is as good a Unix as any for this purpose, since it's already made some inroads into power management (but more will still be needed before this thing can have the stamina of a Palm, a Newton, or even an iBook).
However, what the heck are they planning on using for a GUI? Relying on X will forever write this thing off as a toy, because the interface standards aren't there (and the bloat is unforgivable). The other main reason people so like those Palms (and to a lesser extent, Newtons and iBooks) is the way the interface is well-adapted to the I/O that's available. Graffiti isn't just a lame version of the Newton's handwriting recognition, but the beginnings of an input paradigm designed to minimise the amount of stylus motion required, and to exploit the familiarity of gesturing (I realised this one day when I noticed just how natural the "backspace" gesture is - ironically, while I was entering initials for some game's high score).
So I don't think this thing has a hope of success without a ground-up stylus-and-tiny-screen interface for Linux (and by extension Unix). It's quite possible that they are working on such a thing, possibly in bits and pieces, but then the big question becomes "will they open-source it?". I certainly hope they can and do, not just because I want to see what they come up with (and I do), but because GPLing their work will make it so much easier to integrate other people's ideas and code. And that in turn could end up providing a much more powerful extendability than the hacks for the Palm OS.
I've set up quite a few production servers with both Linux (usually Debian, for sanity's sake) and FreeBSD (pretty much eclipsed Debian on the server side for me in the last few years), including mail (UUCP and SMTP), file services, firewalls, and even the occasional workstation. I could count the number of hours I've spent troubleshooting FreeBSD problems on one hand, while I've probably racked up a solid week or two of fighting with Linux issues (one of those weeks was spent pretty much exclusively on an $!@!! Adaptec Ultrawide controller and 2.0.x kernel). It's not that Linux isn't cool, it's just that it's often hairy as hell. FreeBSD by comparison has in a sense had much of the tech support work done up front, by making the system lean, trim, fast, and extremely well-organised from the start. You see the same effect of prior planning with the other BSDs, too - security for OpenBSD, portability for NetBSD. Linux by comparison is a bit of a kitchen sink.
All that translates to less of a need for tech support, but it's just as important to note that what support *is* needed will have to be that much more expert and focused. Not that BSDI will have any problem with that, but there's simply a higher expectation of sanity and function from a FreeBSD sysadmin than a Linux one, kind of like the difference between a Mac and Windoze user where consistency and ease of use are concerned.
Slashdot Mirror
Now all they need is a game as fun and addicting as Kaboom! to download. ;)
Huh? A code violation is a code violation - being big doesn't give you an excuse to make more of them. Rather, it makes you more responsible to avoid making them, because the effect is magnified when you do.
If it were "accidents" or even "fires" I'd agree with you, but that's not what we're talking about here. Violating some code occurs because the company chose to do things that way. It's not a question of scale, but of policy.
>Clean rooms are "cleaner than hospital rooms," Oswalt said. "I'd rather live there than be on the street."
/. posters' denial of that idea; tough to reconcile while you use your $1500 computer to read the article, isn't it? Did you really think $1500 could buy any sort of environmental control and worker protection? Somebody had to pay for that stuff you're using, and it sure wasn't you.
What the hell kind of meaningless statement is that? Even for a corporate spokesthingy this is idiotic. Not that I wouldn't like to see it happen; kind of like the Chinese officials responsible for airline Y2K readiness (the sky is falling, indeed). Too bad that really was a chicken little story, but this isn't.
The whole consumer electronics industry (including and especially computers) has always rested on inexpensively poisoning people too poor to have a choice in the matter. It's amusing to watch the
The main problem with this idea is that you're probably looking at combining a number of different technologies in addition to speech commands and X10, and there are more of those in total for Windows (ironic because Windows is inherently harder to control and use than just about anything else). And despite X10's recent nauseating push to quasi-porn spycam marketing, they have been doing home control for decades (I remember seeing an entire house controlled from an Apple ][ at an exhibition once).
One of the neatest command speech apps I've seen was an integrated solution for Mac Netscape (Speech Navigator?) that allowed one to say "Navigator Back", "Navigator Scroll Down", "Open link 'Access Technologies'", etc. It worked amazingly well, but some pages were more accessible than others (the Slashdot main page would suck, for instance, since all the important links have the same name - "Read More..."). Nowadays you could probably write custom scripts to do the same thing with a more scriptable browser, like iCab or IE5.
I've read before that this was indeed the reason for the events in Mostly Harmless - DNA was sick of it all and just wanted to get on with other things. If this question is posed him, I'd be interested to know whether he now regrets having written it in that way and from that frame of mind, or whether it did exactly what it was intended to and he remains glad of it.
Interesting - I too had the crap scared out of me by Doctor Who at an early age (much younger than eight or nine, though). For me it was the Daleks; apparently I'd dive behind the couch every time they threatened the Doctor's extermination. I also had the crap rescared out of me later on by riding in the coin-operated talking Dalek at the Bull Run in Birmingham or London ('cause I was a big boy and wouldn't be scared, promise).
I think the real reason DNA required convincing to allow the release of Shada was that it's just not a very good episode. The incompleteness doesn't help either; it's almost comical to see Tom Baker come out between scenes and say "I managed to escape, but then..."
>release the module under the GPL, immediately, or go to court.
I agree, because the intention of using the GPL has always been to make more code open - the "virus-like" nature that some people condemn is, nonetheless, the point. Companies and authors rigorously defend other copyrighted material every day for their own motives of financial gain or creative control, and legally the GPL is nothing more or less than a copyright. Having them remove the offending code is not the motive for initially using the GPL - opening up the derivative code is.
Removing the code and replacing it with a functional equivalent doesn't even really address what they've already gained from it, either, because it was there during the development effort and its presence will have been partly responsible for the final state of the other, closed code in the project. In other words, not all the damage can be undone (but note that this point isn't likely to be addressed by copyright law - in fact the idea is more akin to patents).
However, since not everyone does have your resources, there need to be legal funds in place to deal with these cases.
> computer languages are completely trival when weighed against computer languages
Uh, replace the second "computer" with "natural" or "human". Oops. Maybe I should go back to expressing myself in C for a while.
I agree with your argument here (that designed languages aren't on the same level as natural ones), but your example is weird. How is C an evolved language? It's just as designed as Pascal is (in fact it was designed on two occasions, to its considerable detriment the second time). The two languages just have considerably different design goals.
;) The computer version of Java certainly has its ambiguity, but the intention was always to design it out.
;)
Perhaps you're suggesting that the ANSI committee played a role analogous to the Academie de la Langue Francaise? The problem is that the analogy is too unbalanced - computer languages are completely trival when weighed against computer languages. They also have rather opposite goals; C and Pascal are designed to clarify and limit the range of expression (assuming one agrees that programming can be expressive, which I do - but then I'm a coder), while natural languages largely try to broaden it. Look at a word like "aimer" in French; it's codified by l'Academie, but the vagueness of its meaning is intentional, and in fact integral. Natural languages are full of stuff like that - right now there are a bunch of old men on the island of Java speaking the formal male language and trying to trip each other up with that kind of nuance for their version of karma points.
It's just a bit trite to state that people use language to communicate, because you haven't defined (and really can't define) what communication is or is for. In fact it's for so many different things that attempting to define the "problem space" is almost arrogant, and certainly doomed (see my other long-winded posting at the root of this thread). I think this again goes back to the lack of real analogy between computer and human language; computer languages do have (and exist because of) a finite problem space, but people talk doesn't.
I do agree with the idea that our children's children will be speaking a pastiche of languages, though. I just hope that there's more than one pastiche left around, not a monoglot.
"Si" is a kickass word.
The idea of limiting the scope of human expression in the name of easier commerce is one of the most frightening aspects of the free-market agenda.
;).
Language isn't merely a means of communicating ideas, it helps define the range of what you can and can't consider. Language isn't thought, but it crystallises thought (and that one's not mine, I paraphrase Samuel R. Delany). If thought is the probabilistic wave function, language is what lets it collapse into a finite meaning and nuance and emotion that you can express to another human (that one's mine). But when you collapse a wave function into a particular state, you irretrievably lose an infinite number of other possible states. Killing off the hundreds of non-English languages on this planet will cut us off from things that we simply can't imagine (precisely because we'll never again have the words to express them).
I used to be bilingual in French and English, though in recent years I've lost the sexier of those two languages for the more technical (how dumb am I). At one time I could think in two languages, and I was often struck by the fact that I had different thoughts available to me depending on which one I was in, and even more resulting from the play between the two. If you've never taken the time to learn another language (and by that I mean the only way that really works, by moving somewhere where people will talk to you in it exclusively until you think it when you wake up in the morning), you can't imagine how much it can enrich your experience and insight, and I can't recommend it highly enough ( for which I blame the limitations of language
A weak example of the sort of thing I'm blathering about is the different perspective that some native North and especially South American people have about the nature and passage of time. Hopi people are (somewhat but not entirely apocryphally) credited with an picture of time as a sort of frozen landscape, for instance. It is possible to get that sort of insight from a European speaker's perspective (peyote helps, just ask Carlos Castaneda), but it's a lot harder. If you could learn Hopi from a native speaker, it might make a lot more sense. Maybe you'd go on to build an FTL drive, who knows? One might argue that it's only a common *additional* language that's under discussion, but history has shown that pressing for one dominant language will slowly kill off the others (to seriously argue otherwise now seems naive, not to mention insulting to those cultures we've already killed off 'round here). The point is that that's about as smart as extinguishing all those possible cancer cures in the rain forest. You just never know what you're losing.
>In fact, any rational person would expect these peoples' correlational study to turn out as it
;). I agree with much of what he was getting at, but he draws no real conclusion other than "think carefully over the implications of research results". What some readers may be missing is that this is a basic credo in interpreting *any* sort of research in the social sciences (not that they can be blamed for that - the mass media sure doesn't get it). Of course correlation doesn't imply causation, but it certainly doesn't argue against it. Even the tired old ice cream example is flawed; how do you know that summertime sugar rushes don't combine with heat to induce aggression? You can't say it doesn't any more than you can say it does.
>did...not because video games cause violence but because violent personalities are probably more
>inclined to play violent video games. Which would take all responsibility for this violence off of
>the video games' shoulders.
I think you've misinterpreted both the original results and the critique. The initial aggressiveness of the subjects was controlled for in the experiment; basically, everyone got a go. I do believe there were confounding factors in the noise-blast portion of the experiment (which the critique gets close to discovering - for instance I'd be more concerned about the fact that Wolf 3D is more adrenalising than Myst (even though it bores the heck out of me), and thus likely to make people less sensitive to any kind of critical choice, noise-blast-duration or anything else). Between-subject difference wasn't one of them, however; this is one of the most basic elements of research design, and no psych journal would publish a study that was so easily confounded in that manner.
Like the author of the critique, I'm a tech type with a lot of video game experience and a psych degree (convincingly named a B.S.S.
Common sense is often the best tool we have in this sort of area. Does playing a little Quake or Marathon turn you into a monster? Nope, but playing a hell of a lot of it really will tune you out of reality and skew your idea of what's reasonable to do IRL. Been there, done that (but it was MUDs and not 3D shooters, coincidentally while I was supposedly taking that psych degree). The real danger of twitch games isn't as much the violent content as the addictiveness; the violence just isn't a great ingredient in the kind of mild dissociation that results from doing anything out of balance. Any kind of science requires a healthy amount of agnosticism, and the thing you have to be most agnostic about is the value of Science itself.
There's one other thing I've noticed about mouse and keyboard use that might bear mentioning. Any physical device but the most tank-like will wear out more quickly if you use it harder, and most people click and hold buttons and hit keys much harder than they need to. One reason my old ADB mouse lasted so long was probably the fact that I almost obsessively try to use a light touch wherever possible. The nicest thing about doing this is that you'll also be preserving the other, more important parts of the mechanical input system - your fingers and wrists. If your mice wear out consistently more often than other people's, you might want to ask someone to watch you compute and see whether you're unintentionally being a little harder on yourself and your equipment than you need to be.
Manufacturing quality and cost still makes a difference, though; the last University lab I administered had 10 (pre-USB) Macs and 10 PCs, and it was only the PC mice (M$) that had problems. The Macs were more heavily used, too (I'll leave aside questions of whether GUI design inconsistency and unreliability increases people's stress and causes people to press more anxiously on the Wintel mice, though it probably does). In fact they were constantly used, twelve hours a day. And there's the obvious corollary that a higher quality button will probably respond more consistently in the first place, making it less likely to create hard-clickin' habits.
Anyway, that's enough out of me for this thread. Wonder why this subject wasn't deemed interesting enough for the main page?
FreeBSD "non-async" mounts differ a bit from Linux's idea of "sync". Linux's async is completely async, as in it writes data and metadata willy-nilly as the opportunity arises. Its sync mount is just the opposite, writing everything synchronously in an anal-retentive manner that's just too slow for most real-world use. FreeBSD's async mount is the same (dangerous), but the default mount is actually "non-async" which offers a sort of best-of-both compromise where metadata is written synchronously (you can also make a UFS filesystem completely synchronous, with roughly the same performance penalty as on Linux).
/papers/CSE-TR-254-95/ that gives some explanation of the existing sync/non-async/async scheme as well.
Softupdates is very cool, but it's not really journalling AFAIK. It's just a very well-thought out extension to the existing FFS "non-async" mode that knows how to ordering metadata writes so that a crash can always be recovered from, and so that it knows which ones it can be lazy about. Thus both performance and reliability are improved, and it accomplishes one of (not all) of the goals of a JFS, but in a fairly different manner. There are still benefits to be had from adopting a real JFS, though (I'm pulling for SGI's XFS). I understand softupdates is also due to be released fully free under the BSD licence, once the author thinks it's ready (it's part of the distribution now, you just have to create the symlinks in indication of your acceptance of the current licence). There's a white paper on softupdates at http://www.ece.cmu.edu/~ganger
I think this is simply a consequence of the poor manufacturing quality of the mice that you and most other people have used. I've never found those Sun mice or keyboards (any revision) to be worth squat, and Logitech isn't exactly the Cadillac of consumer devices either - they're just another company that sells mass quantities of low-margin plastic stuff as cheaply as possible. If you want good input/output equipment, you've always had to pay for it. Though it's only useful as an example (not for X, given the single button), Apple's older one-button mice and notebook trackballs were built to last - the ADB Mouse I that came with my Apple IIgs is still going strong after 14 years (about half of them very heavy-use) and countless thousands (millions?) of clicks. Likewise, I used a Powerbook Duo for at least five years without a problem, and it was bought used. Both of those used the same tried-and-true microswitch for the clicker, actually (made in the United States for whatever that's worth - nowadays they're from Malaysia, which coincidentally means the
people who made them probably got paid crap to boot). I also had a decent mouse on an SGI Indy2 once, but then the computer cost $50k (and SGI has sold junk too).
Contrast to Apple's current offering, which besides the love-it-or-hate-it design just isn't any better quality than any other random PC crap, Microsoft, Logitech, or whomever - expect all these things to break, and quickly. The leaf-switch trackpad button on my last Powerbook (2400), which was built by IBM and sold by Apple, wore out after four months. (Then again, the whole notebook died a year after that, and then again another seven months after having the dead motherboard replaced at my cost. Bye, Apple (and by implication, IBM)).
There are better devices out there, but you won't find them at your local megamart. I've never heard anything bad about a Contour mouse, for instance; besides the fact that they have an actual ergonomic design (no hockey pucks or shiny tail-lights here), you can get them sized to your hand, and even right or left handed as appropriate. The same applies to keyboards (the best ones going are made by Kinesis, and they're totally worth the one-time cost). Now that there's a reasonable cross-platform attachment standard that probably won't disappear for a while (USB), it seems particularly worthwhile to spring for some really high quality, lasting input devices that you can take with you from upgrade to upgrade.
In other words, the x86 PC accessory industry you've grown up with is a poor horizon. There's just no doubt that all of the mass-market stuff out there is complete crap (especially anything that comes with the computer system when you buy it). Look to the people trying to provide small-volume ergonomic devices, and chances are you'll find something that's built to last as a bonus.
I interpreted that rule in this way too, but now I suspect they were intended differently. I think that rather than the semantic interpretation of a site that would "link" via an HTML anchor, the author probably had the broader concept of "to link to" in mind, as in the English verb. It's a bit ambiguous, but...
...Of course one could argue that the reader's interpretation of "link to" is an integral part of their next-URL choice, and thus of the interactivity (which is otherwise sparse IMHO), in which case the rules work just the way they're supposed to.
As for whether it should have no rules at all, what would be the point? It'd just be a random URL submission page, and there are more than enough of those, thanks.
>Now, the Church clearly doesn't have a legal leg to stand on to prevent sales (and if they sell it
>anyway, why would they, I mean, the resale market through E-bay won't really effect their bottom
>line to the extent legal fees will), but they can probably protect certain terms.
I expect the CoS's legal fees are nil; all their lawyers would be scientologists (it's a natural fit, after all, you can apply your skills of harassment and irritating bafflegab in two directions at once!).
Interesting document; I've never bothered to read it before (mostly because X/Open is pretty irrelevant these days). According to that, just about anything is an abuse of the trademark, including your *Nix (they cite UN*X, but it would presumably apply). In fact they'd much prefer that you never, ever say anything about Unix (my preferred spelling) without fully stating your terms, as in "UNIX® Operating System", which is perhaps admirably accurate, but doesn't lend itself much to conciseness (ironically enough for an OS with mostly two-letter commands).
The paper taken as a whole is actually pretty absurd; it just goes too far. Even if the trademark weren't diluted all to hell, we're basically talking about four letters; how many slightly similar variations can they reasonably expect to control?
In any event, I don't think the original poster was commenting on the names of the systems at all; s/he was pointing out that software that conforms to the Linux API generally conforms to the Unix API (sorry, I meant the UNIX® Operating System's Application Programming Interface). In other words, that it would be nice if people who've adopted and started coding for Linux would discover that they're actually coding for a much broader audience (with very little extra effort, or none). Which is actually the source of the whole UNIX trademark dilution problem in the first place.
>The spooky part is that the corresponding random bit on the other end changes instantaneously.
:)
Yup, it was to this which I referred. The FTL-communication part is simply what you state: that particle a "knows" some element of state about particle b instaneously, regardless of the distance seperating them. Constructing a thought experiment where FTL communication appears to occur does depend on the definition of "communication", of course, and that term is pretty overloaded in this thread because the original article is about a encrypted digital human communication system (which obviously works at sublight speed). It seems to me that this system is all about modulating the higher-level communication (ie. the venus idol picture) with the lower one (the correspondent particle states).
I'll see if I can dig up the original reference somewhere; it was a lot more persuasive than I'm being.
It is possible to think up circumstances where particle "entanglement" creates the paradox of FTL communication (between the particles, and anything which resolves their state). Though paradox may not be quite the right term, since in many ways the lightspeed limit has nothing to do with quantum mechanics, and entanglement is AFAIK a purely quantum mechanical notion (I recall an article a few years ago in some lay science rag discussing how the c limit is more like a choice Einstein made to make a relativity model possible, and how he pretty much rejected quantum theory wholesale, albeit for more philosophical reasons).
>The task itself imposes the minimum level of complexity.
;)
>Bad user interface can increase the complexity that the user has to deal with,
>but even the best user interface can never decrease complexity below what the task demands.
I find this an extremely insightful point (if I had any moderation points at the moment I'd say so in a different manner), but I'd note that it's not the complexity of the task per se that's the issue, but the number and type of options available to the user.
That is, we tend to be inundated by choice, and a good UI tries to minimise the choices in order to keep them manageable. In fact, I suspect that intentional channeling of effort on the part of GUI designers is why a lot of self-proclaimed old school types fear and shy away from GUIs (especially ones that really try to make this point work, like the Mac) - it feels like choice being taken away, because it is (I should note that I find such a reaction naive, because the choice was necessarily similarly limited in whatever UI the neo-neo-luddite previously preferred, a CLI for instance - it's just less visually obvious and perhaps actually more insidious because of that). It's not just the choices the user that need to be managed, but the choices a developer might make (for instance in presenting the user's choices in some nifty neato way). But then we get onto the teeter-totter of consistency vs. creativity, and I'm not playing there today.
The point about making things appear too simple - which I'll recast as obscuring choice that the user or some subset of users really needed to be aware of - is well taken, though, and may be part of a larger point where the user needs to be aware of the simple fact *that* other choices have been obscured in the name of ease-of-use, a sort of meta-UI design.
Actually, I hate LILO. I'm (genuinely) curious what the people posting in its favour like about it - it seems to me that it's not so much the favourite as it is the sole viable option, currently. In particular, have they used other schemes, like FreeBSD 3-4's multi-stage bootloader? A real CLI that can actually do stuff like read a filesystem, name a kernel by sight, and dynamically switch devices even from the first-stage loader in the boot block (not to mention from either a serial line or a console, automatically probed for or manually switchable at boot time). The next stage loader after that can dynamically preload modules, among a host of other useful features. And I don't have to update the MBR on the raw disk (!) every damn time I rebuild a kernel.
LILO has been due for replacement for a looong time, and it should probably take the current reliance on the awful MS-DOS fdisk style partitioning scheme with it (for a slice scheme like the BSD and many others use, or better still a completely flexible named-partition design like the (gasp) Mac has had for years). Really, these are areas that have been addressed by other Unices for years, including the free ones.
I've long thought that the Unix kernel is a perfectly good choice for PDAs - in fact it's one of the reasons microkernels are a good idea, since one can use a scaled-down Unix "server". Linux is as good a Unix as any for this purpose, since it's already made some inroads into power management (but more will still be needed before this thing can have the stamina of a Palm, a Newton, or even an iBook).
However, what the heck are they planning on using for a GUI? Relying on X will forever write this thing off as a toy, because the interface standards aren't there (and the bloat is unforgivable). The other main reason people so like those Palms (and to a lesser extent, Newtons and iBooks) is the way the interface is well-adapted to the I/O that's available. Graffiti isn't just a lame version of the Newton's handwriting recognition, but the beginnings of an input paradigm designed to minimise the amount of stylus motion required, and to exploit the familiarity of gesturing (I realised this one day when I noticed just how natural the "backspace" gesture is - ironically, while I was entering initials for some game's high score).
So I don't think this thing has a hope of success without a ground-up stylus-and-tiny-screen interface for Linux (and by extension Unix). It's quite possible that they are working on such a thing, possibly in bits and pieces, but then the big question becomes "will they open-source it?". I certainly hope they can and do, not just because I want to see what they come up with (and I do), but because GPLing their work will make it so much easier to integrate other people's ideas and code. And that in turn could end up providing a much more powerful extendability than the hacks for the Palm OS.
I've set up quite a few production servers with both Linux (usually Debian, for sanity's sake) and FreeBSD (pretty much eclipsed Debian on the server side for me in the last few years), including mail (UUCP and SMTP), file services, firewalls, and even the occasional workstation. I could count the number of hours I've spent troubleshooting FreeBSD problems on one hand, while I've probably racked up a solid week or two of fighting with Linux issues (one of those weeks was spent pretty much exclusively on an $!@!! Adaptec Ultrawide controller and 2.0.x kernel). It's not that Linux isn't cool, it's just that it's often hairy as hell. FreeBSD by comparison has in a sense had much of the tech support work done up front, by making the system lean, trim, fast, and extremely well-organised from the start. You see the same effect of prior planning with the other BSDs, too - security for OpenBSD, portability for NetBSD. Linux by comparison is a bit of a kitchen sink.
All that translates to less of a need for tech support, but it's just as important to note that what support *is* needed will have to be that much more expert and focused. Not that BSDI will have any problem with that, but there's simply a higher expectation of sanity and function from a FreeBSD sysadmin than a Linux one, kind of like the difference between a Mac and Windoze user where consistency and ease of use are concerned.