I just wish people would remember all the _good_ parts of trusted computing.
TCPA is going to be bad for more reasons than just Palladium... it's going to be a major headache for IT departments trying to cope with software that is actively unfriendly. Why? It's about visibility. When an IT department needs to replace a legacy app, write bridge code to shuffle data b/t two different software systems, or make revisions to a relic in-house app, the amount of visibility will determine how quickly and cheaply the change can be accomplished.
Visible things include: good documentation, available source code, standard protocals, open data formats, strongly defined interfaces, generous/lax security, unencrypted traffic, non-regulated/classified data, informative error messages, enthusiastic vendor support, open bug databases, and software-oriented community forums (yay Google Groups!).
Invisible things include: missing/shoddy/incomplete documentation, overly-flexible products, binary network protocals and file formats, marketing-centric websites [heh... just try to find technical info about Crystal Reports], "friendly" error messages, abandoned development platforms, and (getting to the point)... stuff that's too locked down.
DRM and trusted computing will add yet another layer of flaky security that prevents casual intrustion while seriously hendering IT. Businesses will be tantalized by the idea that they can precisely control how a memo get distributed, archived, and destroyed. They will be oohed and ahhed that they can enforce their "email retention policies" through the use of TCPA. But this will come with some heavy costs... of which visibility is one of the major ones. I can see it now:
Client: "Here's that email you needed to hook up system A to system B, but I can't send it to you. It says it's protected. I tried taking a screenshot, but it came out all black. I can't seem to print it out either. We could probably call Ginger and find out who could give the authorization to transfer this, but she's not here today. How about I just read it to you over the phone?" [Stupid DRMish Feature]
Product Expert: "Oh yeah... to import text records into RiskModeller3000, you have to create an executable and pay the vendor a wad of cash to sign it. Only then will RiskModeller be willing to execute your binary and munch in the text it produces." [Stupid Licensing Scheme]
Packaging Expert: "To transfer this program from our testing environment to the produciton environment, you'll need to recompile the binary and sign it with this 'production certificate'... hope your build environment hasn't shifted around much or you'll blow the integrity of all that 'final release testing' your clients just spent four weeks on." [Stupid Security Requirement]
Visibility affects the agility of business and the cost of IT. It's not just an abstract good... it provides lubrication for business IT and reduces real cost. A company with a lot of visibility will be more agile and flexible than one without it. And, in the final analysis, a society with visibility will generate more wealth than one that gets too tangled up in an artifical form of security. TMCA is basically bad, because--while it could have good uses--it will ultimately reduce visibility and harm society.
It's not just about pirating MP3's... it's about the creation of real wealth and new technologies.
Sometimes the big three (William Gibson, Neal Stephenson, and Bruce Sterling) seem to be a little hit-or-miss. To read some of the hits, try out Holy Fire or Schismatrix (my gospel!).
Whoa bud... I respect Stallman, but he gets too preoccupied with "doctrinal" issues, and that lessens the impact of his message. It's kinda like have your best warrior distracted in battle because he's hung-up on how the battle emblem was designed.
nice to see such a clear, concise and complete dismissal of SCO
Yeah... but did anyone get the sense that Stallman read the draft essay and had Eben inject that paragraph about calling it 'GNU/Linux' instead of just 'Linux'?
Headline: Microsoft Bankrupt, Linux Rules the World
Stallman: Ahh!!! It's GNU/Linux, damnit.
Headline: Linux Marketshare 60%, Microsoft GPL's Windows
Stallman: Noooo... it's 'GNU/Linux'... Linux is only a kernel!
The only other two options are... to maintain the current ambiguity, which is also obviously undesirable.
You're going to have to create a lot of ambiguity to get to your Gibi heaven. Is the small benefit to pedantisism really worth the cost of conversion? This is one standard that I'm happy to ignore.
According to my understanding of the English language, the parent was saying that Scheme is the most beautiful, and probably the most practical language he's ever seen.
The original post was unintentionally ambiguous. The phrase "the most x, if not the most y" can be interpreted either way. If you say it aloud, you can put a hesitant emphasis on the "if" and say the remainder of the phrase in an undertone to indicate that the subject is not very y-ish at all. This contradicts the more common usage of this construction.
There are a couple of sources of error here:
The phrase itself is suspect... you might say that the common usage contradicts the syntactically "correct" interpretation chosen by the author. Languages frequently develop flaws like this (e.g., like how the word "literally" sometimes means "figuratively" [as in "Bill literally killed me!"]).
The author errored in (a) using a suspect phrase and (b) putting his verbal thoughts on paper without mentally filtering for shifts in intonation semantics.
The reader errored in not deducing the author's meaning from context... the long lead-in (and the obivous impracticality of Scheme) hints at the author's true meaning.
What's amazing about the human mind is that messages usually do get through intact, despite all the sources of errors. The message sent is never the exact same as the message received (first law of communications), but it's usually close enough.
This goes to show once again that no technology is inherently good or bad. It is the application of said technology where we must collectively learn to act more responsibly.
Good versus evil, inherent versus applied... your statement may be correct, but I object to the way you view the world. A more effective way of summarizing DRM is that the technology will tend to be applied in bad ways by human beings. Maybe for another sentient species it will be a good technology, but for us it will be a costly pipe dream.
And as for gaming... there are better ways to solve this problem. How about a web of trust technology built into gamespy and other game-finding programs?
I have yet to see any instance where C could be used, but C++ couldn't.
Your statement is technically correct, not just because C++ is a near-superset of C, but also because both are Turing-complete and have equivalent low-level access to the underlying hardware (thanks to the assembly-code embedding, the raw memory-handling semantics, and the macro preprocessor).
In other words, your statement is trivially true. Pragmatically speaking, the (relative) simplicity of C makes it a better language in many real-world situations. For instances, you blame the shortage of C++ compliers for embedded devices on economics and not on the "inherent limitations of C++". But it's exactly the intrinsic complexity of C++ that limits the number of compilers that can be made for them. By contrast, how many different Lisp/Scheme interpreters are there? The intrinsic simplicity of Lisp means that you can write a basic interpreter in just a few hours. (Of course, being simpler-to-write-an-interpreter-for doesn't mean simpler-to-think-in, so Lisp mainly attracts academians.)
Another example: as you mentioned, in C++ you don't pay for what you don't use. But you do pay for what others use. That is, your code has to interact with other people's code and take into account the specific language features they use. Thus, you end up using parts of the language you didn't want to have to deal with.
This has even wider implications if you're a project manager: you may want to limit your programmers to C so that you can:
easily develop bindings from other languages (since every damn language ever made has a proven, straightforward, well-documented way of interfacing with C).
easily rely on design techniques that require writing code-parsing/manipulation/generation tools (which are easier to write when targeting simpler syntax and semantics).
easily find cheaper/better labor (since the set of C expertise is a superset of C++ expertise [the corollary of C++ being a superset of C]).
easily ensure that your libraries/APIs are usable by a wider audience.
easily support a wider variety of build environments
I'm not saying that C is always better than C++... I'm just pointing out that C's simplicity affords it tangible advantages that you won't get using C++, especially in a multi-developer environment where one programmer's design choices will impact the productivity of his peers. Neither am I saying that C is simpler than C++ in all respects. It's simpler syntactically and semantically, but at a behavioral level, C++ is going to let you create more intuitive high-level API representations of many problem domains (e.g., like scene graphs and simulations).
Concerning this, I do have a solution to this for you that would solve the problem instantly:
Using Windows instead of *nix*.
Ha... the keyboard-centricity of *nix is one of the reasons I use it. I guess many people balk at the idea of "all that typing" for commands, etc., but it becomes really nice when you learn the right keystrokes.
BTW, your point about Windows doesn't hold very well: I know and use a lot of keystrokes for Windows, Word, NT Emacs, Explorer, etc.
I've been using Dvorak as my primary keyboard layout for the past 5 years.
It wasn't worth it.
Let me back up... in many aspects, learning Dvorak is not a huge deal: you just force yourself to use it exclusively and... 4 weeks later, you've got the hang of it. The first two weeks are really frustrating, as it takes you forever to type out the simplest messages. I suspect that *nix users who know a lot of keystrokes by heart would find this an extremely frustrating (and dangerous) time period. But you get past it.
Going back and forth between Qwerty and Dvorak doesn't take a lot of effort either. If you use both regularly, you develop a sort of duality of thought (as another poster suggested), though sometimes it takes a moment to switch between the two. However, if you religiously avoid Qwerty (like I do), you'll find that your skills become somewhat rusty... it would probably take me several minutes of use before I could get the hang of Qwerty again, and perhaps hours of use before I could nail complex Emacs keystrokes correctly.
So what makes Dvorak a pain? Several things:
First, there's no good way to relabel your keyboard to Dvorak. You might be able to buy a new keyboard, you might be able to buy an overlay, you might be able to swap keys around, you might be able to affix little labels. But these all have their problems, and they generally aren't practical when you deal with several keyboards (many of which belong to your employer). So you learn to type "in-the-blind" on a Qwerty keyboard that the OS remaps to Dvorak.
This causes the second frustration: one-fingered typing becomes impossible. Forget eating pizza while jabbing out a short IM to your friend... you'll have to wipe your hands and put both hands on the keyboard because you can't see the right key... you have to feel it. To prove this to yourself, try typing with one finger in Qwerty while look away from the keyboard or squinting your eyes to blur out the labels. Without proper labels, you lose this multitasking ability.
Gaming also becomes more complicated. I'm not familiar with the DirectX API's, but apparently games can access the raw keystrokes or the translated keystrokes. Ideally, the game (1) uses raw keystrokes for (a) game input and (b) the key configuration screen and (2) uses translated keystrokes for in-game messaging. In other words, pressing a key on the keyboard should send the literal character through whatever engine maps keys to game actions (e.g.: space-->jump, left mouse-->fire primary). And when you type a message to send to other players (or the in-game console), the game should be smart enough to know that you're typing in Dvorak instead of Qwerty. Many games get this wrong... some use raw input for the messaging, which means you have to try and type in qwerty during the heat of the action. Even more frustrating, some use the translated input for the key-configuration screen and the raw input for the game (so on the key-config screen, you have to press Qwerty-X to get a Qwerty-Q in the game). If that makes you dizzy, you've started to get the idea...
Using Dvorak has negative social consequences as well. Coworkers/friends/family get annoyed when they try to use your PC and look up to see that they've typed an entire sentece in gibberish. You end up awkardly leaning over their shoulder typing stuff in for them. Sometimes it can be funny, but people tend to be derisive when they don't understand something strange, at least until you tell them that it prevents excruciating wrist pain. (RSI is the reason I adopted Dvorak in the first place, but I'm not really sure that it has helped as much as Ibprofen + following good ergonomic advice.)
I could go on, but the bottom line is that Dvorak will sometimes bring you awkward and frustrating situations. It may be somewhat better, but it's not a typing Nirvana. This is a clear case where the cost of converting doesn't pay off quickly enough. (Kinda like the Gnome people who put the "OK" button on the right hand side of the dialog box... theoretically better, but frustrating to real users.)
As soon as I get over my fear of relearning all the Emacs/Bash/KDE shortcuts I know, I'll switch back to Qwerty. But I'm not in a rush... it's not that big of a difference either way.
You look at all the shit that's gone horribly wrong with the WWW and how fundamentally worse it is compared to 10 years.
10 years ago, we had the BLINK tag. Now we don't. That's progress.
But seriously: it sounds like you want a nice and tidy online space where everyone diligently prepares material that is meticuously reviewed by third-party editors for correctness and relevance before it is registered and indexed in a global information hierarchy devoid of marketing and mindless blathering "chatter".
Granted: the Web is not an Encyclopedia. It's organic. Sometime--like evolution itself--it can be ruthless, sloppy, and a little cruel. To be successful with it, you have to have secret knowledge, specialized tools, a bit of luck, and a damn good search engine. If you don't know how to use the Internet, you'll end up archiving your emails off of Hotmail, one-by-one. Or your inbox will be deluged with spam. Or you'll be covered in pop-ups before ever you find the really good free porn [yes , it's out there].
Log off the net, or find a way to improve it. While you sit there complaining about the past 10 years, a lot of people have done some really good things to make the Internet a better place: Google, the W3 consortium, and even Slashdot (where the editors and moderation system do a fair job of filtering content for relevancy and bringing some balance of opinion to the forefront... despite many flames to the contrary).
Jon Postel is dead, but curiosity and a desire for good engineering will continue to carry humankind into the Information Age against the waves of shameless commercialism and the reckless wrangling of unconstructive, politically-motivated dialogs.
The sensation excited in the human eye by light with a wavelength at or near 510 nm.
How would you move Mount Fuji?
It's going to take lots of heavy equipment, a large labor force, and ~16 rail lines in parallel to the destination site. Please sign this waiver and wire 11.6 tillion Japanesse Yen to my account.
How would you design a remote control for venetian blinds?
Ha ha... silly. Why would you want a remote control for your blinds? Everyone I know just hooks a servo up to their old 802.11b cards and writes a device driver to control it over the network.
...
Questions like these were great ones to ask the UseNet Oracle. I got a great response once on the manhole cover question...
No offense, but I hope nobody uses your license. The freedoms afforded by free software are meaningless if legal issues prevent you from merging two apps that are intended to be free. Case in point: when TrollTech originally open-sourced Qt under the Q Public License ("QPL"), it was incompatible with all the GPL code that's already out there. TrollTech may have had legitimate concerns about technical operation of the GPL (and its ability to protect their code), but their actions caused a lot of pointless flamewars back and forth.
Worse, people who wanted to combine GPL'd code with QPL'd code could not do it for legal reasons: even though both licenses had the same basic intent, they both excluded each other.
TrollTech eventually consented to a GPL release of their code. As a result, projects like ksql (which provides a KDE front-end to mysql) are able to exist.
Pragmatically, we'll have more collective freedoms if there's only one viral license in the community, and the GPL is pretty much the 800-lbs. gorilla in terms of its established code base. Is it the absolute best? I doubt it... anything can be tweaked and tweaked further. Don't get me wrong... I'm not trying to tout the GPL or FSF or RMS or copyleft in general... I just don't want to see pointless fragmentation... it causes a lot of uproar, duplication of energy, and an overall loss in freedom. (Note that the community has room for plenty of non-viral licenses and public domain software... those are good too, especially when they are forward-compatible with the GPL).
All of that said, there might come a day when it would be best for the community if Stallman were to release the reins to the FSF and establish a process by which the community could guide future revisions to the GPL. I'm guessing that, for Stallman, that might be difficult...
Re:10 Years Won't Solve Chinese Piracy of Movies
on
Foiling Cinema Pirates
·
· Score: 4, Insightful
So by your arguement, if China starts shooting Americans at random, it's ok because it's part of their culture.
Don't be a smart-ass... the people who believe in complete, total cultural relativism are just as naieve as the people who believe that their culture's values define a universal ideal to which all other cultures should adhere. In reality, morals emerge from the day-to-day experiences of human existance. E.g., "do unto others as you would have them do onto you".
Things like murder, rape, and violence have been universally condemned by every culture. That's because it makes people feel bad. Of course, not that every culture has also had exceptions to these rules... things like "justified homocide", "holy war", "preemptive strike", prostitution, marital rape, and the "he-had-it-coming" defense... the badness of the experience is absolute, but the rules with which a culture encodes it vary widely.
It's a wide world though, and cultures start to have a greater number of opinions on things like "nonmarital sex", "blowjobs", "dissedent speech", "spitting on the ground", and "pirating music". My point in the previous post was that we should realize that there is a great room for flexibility here, and it's ultimately up to the Chinese where they want to take it.
I, for one, think humanity as a whole would be better if we severly curtailed the role of copyright and patents. It's probably not optimal to abolish them altogether, but I we should radically rethink them. Think about it: if no copyright existed, people would still be making music, art, books, and software (open-source is a good example of the latter, but it is by no means the only example: a lot of software that is produced is done so because it will pay for itself). If no copyright existed, we might have less quantity and less special effects and less pop-garbage merchandise. But it might be made up for in terms of stronger culture and localized talent with richer variety.
Stepping even further back (and ignoring my particular stance on intellectual property), I think there's a lesson here about globalization: globalization brings with it legal and cultural homogenity and more centralized control. This is bad... the human race will be more robust if reasonably-sized regions can experiment and evolve independently (much like the U.S. gets an advantage out of different states experimenting with different policies [e.g., notice how all the lawmakers have rethought deregulation of the power industry after that little experiement in California failed]). WIPO's ideas about intellectual property may be ideal (*cough*bullshit*cough*), but I'd much rather us find that out by having different nations experiment with different IP models than to have WIPO impose its will on the world and have reform come only decades later after reform, revolution, or revolt have had sufficent time to brew.
The only thing we have to fear is a world where nothing can change...
Re:10 Years Won't Solve Chinese Piracy of Movies
on
Foiling Cinema Pirates
·
· Score: 4, Insightful
This problem of pirating movies and software is a cultural problem, not a legal problem. Most Chinese simply believe that stealing intellectual property is acceptable.
I think you are the one with the mindset problem. "Ownership" is an abstract idea that cultures choose to enforce through the mechanism of government. It makes a lot of sense for items that are fundamentally scarce... material goods, livestock, land. It may make some sense for encouraging innovation and the collection of data that would otherwise not be collected. Maybe. It makes little sense for cultural artifacts... things like music, art, and stories will be produced inevitably, and it's been that way for millennia, and some of our greatest cultural treasures have been created by copying and building on past innovations. But I guess the way you see it, Shakespeare "stole" all his materials and should tossed into the slammer with other murders and rapist.
Let China do whatever the heck it wants to do... maybe it's better, maybe it's worse, but we don't have the grounds to tell them what their culture should be like. (And if you haven't noticed, an awful lot of people in Western culture rationalize the "theft" of music... perhaps our laws should be changed to match our actual beliefs, and not the economic will of corporate content controllers.)
Perhaps we should not blame the users, but instead accept that passwords are themselves a poor design.
Wow! Good post... it's easy to blame the user, but this problem is obviously endemic to the way humans think, especially with the increasing number of passwords we have to keep track of (as you pointed out).
I think of myself as security-conscious. I generate random passwords for all of my accounts (either that, or I think up something that is pretty darn close). I reuse passwords, but only in different "stratas" of service. And anything that has money behind it (online-shopping accounts, etc.) has its own unique password.
However, everybody has their limit. Mine is the two-month expiration on passwords at work. It's a good policy, but the system can't recognize that I'm choosing strong passwords and protecting them responsibly. The rules are numerous: I can't use any of the last 13 passwords. I must have an alphanumeric mixture. I must have at least 6 letters. Sigh... lump it in with a half-dozen password for generic ID's spread across various databases and applications and it gets frustrating... it almost makes me want to use blank passwords, a la RMS. Too bad the system doesn't accept zero-length strings. I think I'm going to rebel and keep a big, fat, obvious list of passwords posted in my cube... 14 of them.
If my employeer is concerned about security, perhaps they could install SSH properly on their HP-UX servers so that I wouldn't have to send my password in the clear to login. And perhaps the help line should require a little more than my date-of-hire to reset my password.
(Ah... sorry... it felt good to bitch about that.)
Well, nature took a few million years to come up with this design, and it's actually a pretty good one.
It's pretty good, but nature didn't open source the perception/actuation software. Problems like "walking" are still difficult, especially if you have to worry about stairs, uneven terrain, varying surface conditions, local obstacles, etc. The point of the first poster is that you can avoid most of these problems upfront by choosing a cleverer form factor.
You make it sound like these LISP programmers are allergic to documentation.
Some might say that all programmers are allergic to documentation.:-)
Let's be honest though... documentation requires programmer
thoroughness. It requires active maintenance. And it requires that
the docs be accessible when they are needed. The last one is the big
zinger: when you come across some legacy file format used to connect
different systems, you would like to have ready access to the docs
that define that format. Good luck if the relevant (external vendors |
internal programmers) have disappeared.
XML certaintly has a selling point in that, when you use it correctly,
future maintainers will be able to infer
a lot about the format from a few examples w/o having to dig up
the documentation. That said, they're still going to be a lot of problems
with people:
choosing non-meaningful element names
throwing everything into CDATA sections as binary
trying to directly parse the XML instead of using DOM/SAX (e.g., because they're newbies who
have been let loose with VB or Perl and they don't know better)
trying to represent things in XML that just shouldn't be represented
in XML
creating a new schemas instead of developing/utilizing industry standards
using XML as an extremely verbose method of squeezing RPC calls through a firewall (*cough*SOAP*cough*)
Or you could just use s-expressions, getting a more general syntax than XML with less unnecessary sugar, and the ability to embed code for free.
Both XML and s-expressions are effective ways of representing tree structures, but they tend to work better for different things. As you mention, s-expressions are better at embedding code (and how elegant they are at that! especially for those of us who like to think in terms of second-order function tricks). They also have the advantage of being smaller, easier/faster to edit (with an adequate syntax-hilighting, expression-transposing text editor), and less filled with verbose froo-froo.
XML, on the other hand, exceeds at being more self-explanatory (because entities and attributes have to have a name, wheras lisp programmers are often content to let things be implied by how its all nested, etc.... no one forces them to use as assoc list for everything). They are also more obviously extendable... a new attribute or entity can go anywhere; you might have to modify the schema (which is a self-imposed constraint to begin with), and you might have to modify legacy apps (if they were dumb-knucks who did not follow the "ignore what you don't understand rule), but at least you have a starting point. In Lisp, the things left unsaid can come back to haunt you when you want to end the data format.
All that syntax sugar in XML serves a purpose: it communicates higher level design behaviors and intentions. Q: Why did the programmer make something a processing instruction instead of an entitiy? A: Because the programmer was inserting a piece of information that is almost peripheral to the core data model, that is non-hierarchal, and that only needs to be noted by a particular application. Q: Why did the programmer use a CDATA section instead of a text block? A: Because the data is armored binary that is not meaningful to edit as text.
The power of XML is the power of defaults. True, you could introduce additional conventions on top of s-expressions to allow the self-explanatory structure of XML. You could add mechanisms for specifying schema conventions. You could do all of that stuff, but it would be kinda pointless because by the time you did all of that stuff, you'd have traded the advantages concisenses for the advantages of self-explanatation.
s-exprs and XML both have their place and their respective areas of usage. For many problems, either one would do just as fine. That said, XML is probably better for most business applications (if the choice is between only s-expressions and XML): all of the conventions that have sprung up around it (XSLT, XML Schema, etc.) will make it a boon for data handling.
Simply put, if the masses see "hackers" as evil criminals then that's what "hackers" are. Language is determined by the masses, not by a small minority who get to determine what's PC or right.
Hurrah for linguistic enlightenment! While we knowledge workers
are very use to naming things--establishing strong definitions
for new words or phrases within a specific discipline or project--it
must be remembered that the usage-consensus ultimately determines
what words mean. Dictionaries are ultimately descriptive,
not prescriptive.
Intresting about "hacker", though: I think slashdotters and other
computer geeks have become more accepting of the criminal connotations
while the general public has become more accepting of the original,
more benign definition(s). Anyone care to do some field work?
(While you're at it, see how many members of the general public would
recognize the CSish definition of "string".)
So I'm curious, who actually can make that claim? Nobody immediately springs to mind.
Easy. Go to a quarry, get a slab of granite, and chisel a place for an Ethernet cord to fit in. Call it a "server". It's not big on CPU power or network I/O, but it's as solid and unhackable as they come. All you need to add is adequate physical security, which isn't that difficult given that you can bury it underground or throw it into a deep sea abyss (thanks to its zero-power draw and watertight construction).
It's called a sandbox. Assuming you trust HonestThief, they
can write their software such that it safely execute the code of their
clients. This approach can cut down on effective CPU throughput
(think: Java) if it's not done right.
Note that access to most resources (printer, screen, network, etc.)
isn't necessary for the computations that HonestThief's client's code
would be doing. They might provide a disk cache of some sort, or
even an API to pass messages back out to the network to other
processing nodes. I dunno.
Of course, even trusting that HonestThief does write the daemon
with an eye towards security and sandboxing, it will be hard for them
to get it right on their first try (whether they're pre-verifying the
opcodes or using a full blown java-esque approach).
However, this doesn't really matter in the end: big clients spending
lots of money on processing power have better things to do than
to write virii for which they will go to jail. The biggest danger
would be from criminals who subvert the program (prehaps by
masquerading as HonestThief.com?).
Second, we're not thwarting evolution. We're giving the victims their life back after accidents that Nature never intended. At what point did the Discover channel do a special on "the Drunk Driver's Place in the Ecosystem?" And what natural defense do you propose we evolve to counter this risk? Adamantium skeletons?
This argument is particuraly weak: suppose Bob dies (or gets
disfigured) in a wreck because some dumb drunk got behind the wheel.
It's not Bob's fault, legally or socially. But that doesn't matter
to evolution. Without medical interferrance, people with genes
like Bob's would have lower survival rates than people who had
(1) quicker reaction times, (2) a greater fear of driving at night
(especially on the weekends), and/or (3) adamantium skeletons.
That's not to say we shouldn't interfere medically. We all personally
want medical attention (as you identified), so we have to be willing
to give it to everybody else. Arguments that we should "let evolution
take its course" have historically failed (with the result that
their promulagators have been portrayed as villians). And maybe
there's nothing wrong with basic human compassion: prehaps the
way it holds us together as a society does more for survivability than
fretting over how many children welfare mothers give birth to.
What will happen to the human race? Don't know, but intelligence
isn't all its drummed up to be. Bring on the face transplants:
this is just the beginning of what we will do to our biology...
Slashdot Mirror
TCPA is going to be bad for more reasons than just Palladium... it's going to be a major headache for IT departments trying to cope with software that is actively unfriendly. Why? It's about visibility. When an IT department needs to replace a legacy app, write bridge code to shuffle data b/t two different software systems, or make revisions to a relic in-house app, the amount of visibility will determine how quickly and cheaply the change can be accomplished.
Visible things include: good documentation, available source code, standard protocals, open data formats, strongly defined interfaces, generous/lax security, unencrypted traffic, non-regulated/classified data, informative error messages, enthusiastic vendor support, open bug databases, and software-oriented community forums (yay Google Groups!).
Invisible things include: missing/shoddy/incomplete documentation, overly-flexible products, binary network protocals and file formats, marketing-centric websites [heh... just try to find technical info about Crystal Reports], "friendly" error messages, abandoned development platforms, and (getting to the point)... stuff that's too locked down.
DRM and trusted computing will add yet another layer of flaky security that prevents casual intrustion while seriously hendering IT. Businesses will be tantalized by the idea that they can precisely control how a memo get distributed, archived, and destroyed. They will be oohed and ahhed that they can enforce their "email retention policies" through the use of TCPA. But this will come with some heavy costs... of which visibility is one of the major ones. I can see it now:
- Client: "Here's that email you needed to hook up system A to system B, but I can't send it to you. It says it's protected. I tried taking a screenshot, but it came out all black. I can't seem to print it out either. We could probably call Ginger and find out who could give the authorization to transfer this, but she's not here today. How about I just read it to you over the phone?" [Stupid DRMish Feature]
- Product Expert: "Oh yeah... to import text records into RiskModeller3000, you have to create an executable and pay the vendor a wad of cash to sign it. Only then will RiskModeller be willing to execute your binary and munch in the text it produces." [Stupid Licensing Scheme]
- Packaging Expert: "To transfer this program from our testing environment to the produciton environment, you'll need to recompile the binary and sign it with this 'production certificate'... hope your build environment hasn't shifted around much or you'll blow the integrity of all that 'final release testing' your clients just spent four weeks on." [Stupid Security Requirement]
Visibility affects the agility of business and the cost of IT. It's not just an abstract good... it provides lubrication for business IT and reduces real cost. A company with a lot of visibility will be more agile and flexible than one without it. And, in the final analysis, a society with visibility will generate more wealth than one that gets too tangled up in an artifical form of security. TMCA is basically bad, because--while it could have good uses--it will ultimately reduce visibility and harm society.It's not just about pirating MP3's... it's about the creation of real wealth and new technologies.
Sometimes the big three (William Gibson, Neal Stephenson, and Bruce Sterling) seem to be a little hit-or-miss. To read some of the hits, try out Holy Fire or Schismatrix (my gospel!).
Whoa bud... I respect Stallman, but he gets too preoccupied with "doctrinal" issues, and that lessens the impact of his message. It's kinda like have your best warrior distracted in battle because he's hung-up on how the battle emblem was designed.
Yeah... but did anyone get the sense that Stallman read the draft essay and had Eben inject that paragraph about calling it 'GNU/Linux' instead of just 'Linux'?
Headline: Microsoft Bankrupt, Linux Rules the World
Stallman: Ahh!!! It's GNU/Linux, damnit.
Headline: Linux Marketshare 60%, Microsoft GPL's Windows
Stallman: Noooo... it's 'GNU/Linux'... Linux is only a kernel!
Headline: Extraterrestials Obliterate Eastern Seaboard
Stallman: 'GNU/Linux' everyone, 'GNU/Linux'...
And soccer moms WILL get their just desserts when they get ticketed for going 40 MPH through subdivisions where they lobbied for a 25 MPH limit. :-)
You're going to have to create a lot of ambiguity to get to your Gibi heaven. Is the small benefit to pedantisism really worth the cost of conversion? This is one standard that I'm happy to ignore.
The original post was unintentionally ambiguous. The phrase "the most x, if not the most y" can be interpreted either way. If you say it aloud, you can put a hesitant emphasis on the "if" and say the remainder of the phrase in an undertone to indicate that the subject is not very y-ish at all. This contradicts the more common usage of this construction.
There are a couple of sources of error here:
- The phrase itself is suspect... you might say that the common usage contradicts the syntactically "correct" interpretation chosen by the author. Languages frequently develop flaws like this (e.g., like how the word "literally" sometimes means "figuratively" [as in "Bill literally killed me!"]).
- The author errored in (a) using a suspect phrase and (b) putting his verbal thoughts on paper without mentally filtering for shifts in intonation semantics.
- The reader errored in not deducing the author's meaning from context... the long lead-in (and the obivous impracticality of Scheme) hints at the author's true meaning.
What's amazing about the human mind is that messages usually do get through intact, despite all the sources of errors. The message sent is never the exact same as the message received (first law of communications), but it's usually close enough.Oh, and Scheme is beautiful.
Good versus evil, inherent versus applied... your statement may be correct, but I object to the way you view the world. A more effective way of summarizing DRM is that the technology will tend to be applied in bad ways by human beings. Maybe for another sentient species it will be a good technology, but for us it will be a costly pipe dream.
And as for gaming... there are better ways to solve this problem. How about a web of trust technology built into gamespy and other game-finding programs?
Your statement is technically correct, not just because C++ is a near-superset of C, but also because both are Turing-complete and have equivalent low-level access to the underlying hardware (thanks to the assembly-code embedding, the raw memory-handling semantics, and the macro preprocessor).
In other words, your statement is trivially true. Pragmatically speaking, the (relative) simplicity of C makes it a better language in many real-world situations. For instances, you blame the shortage of C++ compliers for embedded devices on economics and not on the "inherent limitations of C++". But it's exactly the intrinsic complexity of C++ that limits the number of compilers that can be made for them. By contrast, how many different Lisp/Scheme interpreters are there? The intrinsic simplicity of Lisp means that you can write a basic interpreter in just a few hours. (Of course, being simpler-to-write-an-interpreter-for doesn't mean simpler-to-think-in, so Lisp mainly attracts academians.)
Another example: as you mentioned, in C++ you don't pay for what you don't use. But you do pay for what others use. That is, your code has to interact with other people's code and take into account the specific language features they use. Thus, you end up using parts of the language you didn't want to have to deal with.
This has even wider implications if you're a project manager: you may want to limit your programmers to C so that you can:
I'm not saying that C is always better than C++... I'm just pointing out that C's simplicity affords it tangible advantages that you won't get using C++, especially in a multi-developer environment where one programmer's design choices will impact the productivity of his peers. Neither am I saying that C is simpler than C++ in all respects. It's simpler syntactically and semantically, but at a behavioral level, C++ is going to let you create more intuitive high-level API representations of many problem domains (e.g., like scene graphs and simulations).
Using Windows instead of *nix*.
Ha... the keyboard-centricity of *nix is one of the reasons I use it. I guess many people balk at the idea of "all that typing" for commands, etc., but it becomes really nice when you learn the right keystrokes.
BTW, your point about Windows doesn't hold very well: I know and use a lot of keystrokes for Windows, Word, NT Emacs, Explorer, etc.
It wasn't worth it.
Let me back up... in many aspects, learning Dvorak is not a huge deal: you just force yourself to use it exclusively and... 4 weeks later, you've got the hang of it. The first two weeks are really frustrating, as it takes you forever to type out the simplest messages. I suspect that *nix users who know a lot of keystrokes by heart would find this an extremely frustrating (and dangerous) time period. But you get past it.
Going back and forth between Qwerty and Dvorak doesn't take a lot of effort either. If you use both regularly, you develop a sort of duality of thought (as another poster suggested), though sometimes it takes a moment to switch between the two. However, if you religiously avoid Qwerty (like I do), you'll find that your skills become somewhat rusty... it would probably take me several minutes of use before I could get the hang of Qwerty again, and perhaps hours of use before I could nail complex Emacs keystrokes correctly.
So what makes Dvorak a pain? Several things:
First, there's no good way to relabel your keyboard to Dvorak. You might be able to buy a new keyboard, you might be able to buy an overlay, you might be able to swap keys around, you might be able to affix little labels. But these all have their problems, and they generally aren't practical when you deal with several keyboards (many of which belong to your employer). So you learn to type "in-the-blind" on a Qwerty keyboard that the OS remaps to Dvorak.
This causes the second frustration: one-fingered typing becomes impossible. Forget eating pizza while jabbing out a short IM to your friend... you'll have to wipe your hands and put both hands on the keyboard because you can't see the right key... you have to feel it. To prove this to yourself, try typing with one finger in Qwerty while look away from the keyboard or squinting your eyes to blur out the labels. Without proper labels, you lose this multitasking ability.
Gaming also becomes more complicated. I'm not familiar with the DirectX API's, but apparently games can access the raw keystrokes or the translated keystrokes. Ideally, the game (1) uses raw keystrokes for (a) game input and (b) the key configuration screen and (2) uses translated keystrokes for in-game messaging. In other words, pressing a key on the keyboard should send the literal character through whatever engine maps keys to game actions (e.g.: space-->jump, left mouse-->fire primary). And when you type a message to send to other players (or the in-game console), the game should be smart enough to know that you're typing in Dvorak instead of Qwerty. Many games get this wrong... some use raw input for the messaging, which means you have to try and type in qwerty during the heat of the action. Even more frustrating, some use the translated input for the key-configuration screen and the raw input for the game (so on the key-config screen, you have to press Qwerty-X to get a Qwerty-Q in the game). If that makes you dizzy, you've started to get the idea...
Using Dvorak has negative social consequences as well. Coworkers/friends/family get annoyed when they try to use your PC and look up to see that they've typed an entire sentece in gibberish. You end up awkardly leaning over their shoulder typing stuff in for them. Sometimes it can be funny, but people tend to be derisive when they don't understand something strange, at least until you tell them that it prevents excruciating wrist pain. (RSI is the reason I adopted Dvorak in the first place, but I'm not really sure that it has helped as much as Ibprofen + following good ergonomic advice.)
I could go on, but the bottom line is that Dvorak will sometimes bring you awkward and frustrating situations. It may be somewhat better, but it's not a typing Nirvana. This is a clear case where the cost of converting doesn't pay off quickly enough. (Kinda like the Gnome people who put the "OK" button on the right hand side of the dialog box... theoretically better, but frustrating to real users.)
As soon as I get over my fear of relearning all the Emacs/Bash/KDE shortcuts I know, I'll switch back to Qwerty. But I'm not in a rush... it's not that big of a difference either way.
10 years ago, we had the BLINK tag. Now we don't. That's progress.
But seriously: it sounds like you want a nice and tidy online space where everyone diligently prepares material that is meticuously reviewed by third-party editors for correctness and relevance before it is registered and indexed in a global information hierarchy devoid of marketing and mindless blathering "chatter".
Granted: the Web is not an Encyclopedia. It's organic. Sometime--like evolution itself--it can be ruthless, sloppy, and a little cruel. To be successful with it, you have to have secret knowledge, specialized tools, a bit of luck, and a damn good search engine. If you don't know how to use the Internet, you'll end up archiving your emails off of Hotmail, one-by-one. Or your inbox will be deluged with spam. Or you'll be covered in pop-ups before ever you find the really good free porn [yes , it's out there].
Log off the net, or find a way to improve it. While you sit there complaining about the past 10 years, a lot of people have done some really good things to make the Internet a better place: Google, the W3 consortium, and even Slashdot (where the editors and moderation system do a fair job of filtering content for relevancy and bringing some balance of opinion to the forefront... despite many flames to the contrary).
Jon Postel is dead, but curiosity and a desire for good engineering will continue to carry humankind into the Information Age against the waves of shameless commercialism and the reckless wrangling of unconstructive, politically-motivated dialogs.
The sensation excited in the human eye by light with a wavelength at or near 510 nm.
How would you move Mount Fuji?
It's going to take lots of heavy equipment, a large labor force, and ~16 rail lines in parallel to the destination site. Please sign this waiver and wire 11.6 tillion Japanesse Yen to my account.
How would you design a remote control for venetian blinds?
Ha ha... silly. Why would you want a remote control for your blinds? Everyone I know just hooks a servo up to their old 802.11b cards and writes a device driver to control it over the network.
Questions like these were great ones to ask the UseNet Oracle. I got a great response once on the manhole cover question...
Or, to sum it up... instead of a system for resolving disputes, we have an industry for creating them.
Worse, people who wanted to combine GPL'd code with QPL'd code could not do it for legal reasons: even though both licenses had the same basic intent, they both excluded each other.
TrollTech eventually consented to a GPL release of their code. As a result, projects like ksql (which provides a KDE front-end to mysql) are able to exist.
Pragmatically, we'll have more collective freedoms if there's only one viral license in the community, and the GPL is pretty much the 800-lbs. gorilla in terms of its established code base. Is it the absolute best? I doubt it... anything can be tweaked and tweaked further. Don't get me wrong... I'm not trying to tout the GPL or FSF or RMS or copyleft in general... I just don't want to see pointless fragmentation... it causes a lot of uproar, duplication of energy, and an overall loss in freedom. (Note that the community has room for plenty of non-viral licenses and public domain software... those are good too, especially when they are forward-compatible with the GPL).
All of that said, there might come a day when it would be best for the community if Stallman were to release the reins to the FSF and establish a process by which the community could guide future revisions to the GPL. I'm guessing that, for Stallman, that might be difficult...
Don't be a smart-ass... the people who believe in complete, total cultural relativism are just as naieve as the people who believe that their culture's values define a universal ideal to which all other cultures should adhere. In reality, morals emerge from the day-to-day experiences of human existance. E.g., "do unto others as you would have them do onto you".
Things like murder, rape, and violence have been universally condemned by every culture. That's because it makes people feel bad. Of course, not that every culture has also had exceptions to these rules... things like "justified homocide", "holy war", "preemptive strike", prostitution, marital rape, and the "he-had-it-coming" defense... the badness of the experience is absolute, but the rules with which a culture encodes it vary widely.
It's a wide world though, and cultures start to have a greater number of opinions on things like "nonmarital sex", "blowjobs", "dissedent speech", "spitting on the ground", and "pirating music". My point in the previous post was that we should realize that there is a great room for flexibility here, and it's ultimately up to the Chinese where they want to take it.
I, for one, think humanity as a whole would be better if we severly curtailed the role of copyright and patents. It's probably not optimal to abolish them altogether, but I we should radically rethink them. Think about it: if no copyright existed, people would still be making music, art, books, and software (open-source is a good example of the latter, but it is by no means the only example: a lot of software that is produced is done so because it will pay for itself). If no copyright existed, we might have less quantity and less special effects and less pop-garbage merchandise. But it might be made up for in terms of stronger culture and localized talent with richer variety.
Stepping even further back (and ignoring my particular stance on intellectual property), I think there's a lesson here about globalization: globalization brings with it legal and cultural homogenity and more centralized control. This is bad... the human race will be more robust if reasonably-sized regions can experiment and evolve independently (much like the U.S. gets an advantage out of different states experimenting with different policies [e.g., notice how all the lawmakers have rethought deregulation of the power industry after that little experiement in California failed]). WIPO's ideas about intellectual property may be ideal (*cough*bullshit*cough*), but I'd much rather us find that out by having different nations experiment with different IP models than to have WIPO impose its will on the world and have reform come only decades later after reform, revolution, or revolt have had sufficent time to brew.
The only thing we have to fear is a world where nothing can change...
I think you are the one with the mindset problem. "Ownership" is an abstract idea that cultures choose to enforce through the mechanism of government. It makes a lot of sense for items that are fundamentally scarce... material goods, livestock, land. It may make some sense for encouraging innovation and the collection of data that would otherwise not be collected. Maybe. It makes little sense for cultural artifacts... things like music, art, and stories will be produced inevitably, and it's been that way for millennia, and some of our greatest cultural treasures have been created by copying and building on past innovations. But I guess the way you see it, Shakespeare "stole" all his materials and should tossed into the slammer with other murders and rapist.
Let China do whatever the heck it wants to do... maybe it's better, maybe it's worse, but we don't have the grounds to tell them what their culture should be like. (And if you haven't noticed, an awful lot of people in Western culture rationalize the "theft" of music... perhaps our laws should be changed to match our actual beliefs, and not the economic will of corporate content controllers.)
Wow! Good post... it's easy to blame the user, but this problem is obviously endemic to the way humans think, especially with the increasing number of passwords we have to keep track of (as you pointed out).
I think of myself as security-conscious. I generate random passwords for all of my accounts (either that, or I think up something that is pretty darn close). I reuse passwords, but only in different "stratas" of service. And anything that has money behind it (online-shopping accounts, etc.) has its own unique password.
However, everybody has their limit. Mine is the two-month expiration on passwords at work. It's a good policy, but the system can't recognize that I'm choosing strong passwords and protecting them responsibly. The rules are numerous: I can't use any of the last 13 passwords. I must have an alphanumeric mixture. I must have at least 6 letters. Sigh... lump it in with a half-dozen password for generic ID's spread across various databases and applications and it gets frustrating... it almost makes me want to use blank passwords, a la RMS. Too bad the system doesn't accept zero-length strings. I think I'm going to rebel and keep a big, fat, obvious list of passwords posted in my cube... 14 of them.
If my employeer is concerned about security, perhaps they could install SSH properly on their HP-UX servers so that I wouldn't have to send my password in the clear to login. And perhaps the help line should require a little more than my date-of-hire to reset my password.
(Ah... sorry... it felt good to bitch about that.)
It's pretty good, but nature didn't open source the perception/actuation software. Problems like "walking" are still difficult, especially if you have to worry about stairs, uneven terrain, varying surface conditions, local obstacles, etc. The point of the first poster is that you can avoid most of these problems upfront by choosing a cleverer form factor.
Some might say that all programmers are allergic to documentation. :-)
Let's be honest though... documentation requires programmer
thoroughness. It requires active maintenance. And it requires that
the docs be accessible when they are needed. The last one is the big
zinger: when you come across some legacy file format used to connect
different systems, you would like to have ready access to the docs
that define that format. Good luck if the relevant (external vendors |
internal programmers) have disappeared.
XML certaintly has a selling point in that, when you use it correctly, future maintainers will be able to infer a lot about the format from a few examples w/o having to dig up the documentation. That said, they're still going to be a lot of problems with people:
- choosing non-meaningful element names
- throwing everything into CDATA sections as binary
- trying to directly parse the XML instead of using DOM/SAX (e.g., because they're newbies who
have been let loose with VB or Perl and they don't know better)
- trying to represent things in XML that just shouldn't be represented
in XML
- creating a new schemas instead of developing/utilizing industry standards
- using XML as an extremely verbose method of squeezing RPC calls through a firewall (*cough*SOAP*cough*)
But at least it's a step in the right direction.Both XML and s-expressions are effective ways of representing tree structures, but they tend to work better for different things. As you mention, s-expressions are better at embedding code (and how elegant they are at that! especially for those of us who like to think in terms of second-order function tricks). They also have the advantage of being smaller, easier/faster to edit (with an adequate syntax-hilighting, expression-transposing text editor), and less filled with verbose froo-froo.
XML, on the other hand, exceeds at being more self-explanatory (because entities and attributes have to have a name, wheras lisp programmers are often content to let things be implied by how its all nested, etc.... no one forces them to use as assoc list for everything). They are also more obviously extendable... a new attribute or entity can go anywhere; you might have to modify the schema (which is a self-imposed constraint to begin with), and you might have to modify legacy apps (if they were dumb-knucks who did not follow the "ignore what you don't understand rule), but at least you have a starting point. In Lisp, the things left unsaid can come back to haunt you when you want to end the data format.
All that syntax sugar in XML serves a purpose: it communicates higher level design behaviors and intentions. Q: Why did the programmer make something a processing instruction instead of an entitiy? A: Because the programmer was inserting a piece of information that is almost peripheral to the core data model, that is non-hierarchal, and that only needs to be noted by a particular application. Q: Why did the programmer use a CDATA section instead of a text block? A: Because the data is armored binary that is not meaningful to edit as text.
The power of XML is the power of defaults. True, you could introduce additional conventions on top of s-expressions to allow the self-explanatory structure of XML. You could add mechanisms for specifying schema conventions. You could do all of that stuff, but it would be kinda pointless because by the time you did all of that stuff, you'd have traded the advantages concisenses for the advantages of self-explanatation.
s-exprs and XML both have their place and their respective areas of usage. For many problems, either one would do just as fine. That said, XML is probably better for most business applications (if the choice is between only s-expressions and XML): all of the conventions that have sprung up around it (XSLT, XML Schema, etc.) will make it a boon for data handling.
Hurrah for linguistic enlightenment! While we knowledge workers are very use to naming things--establishing strong definitions for new words or phrases within a specific discipline or project--it must be remembered that the usage-consensus ultimately determines what words mean. Dictionaries are ultimately descriptive, not prescriptive.
Intresting about "hacker", though: I think slashdotters and other computer geeks have become more accepting of the criminal connotations while the general public has become more accepting of the original, more benign definition(s). Anyone care to do some field work? (While you're at it, see how many members of the general public would recognize the CSish definition of "string".)
Easy. Go to a quarry, get a slab of granite, and chisel a place for an Ethernet cord to fit in. Call it a "server". It's not big on CPU power or network I/O, but it's as solid and unhackable as they come. All you need to add is adequate physical security, which isn't that difficult given that you can bury it underground or throw it into a deep sea abyss (thanks to its zero-power draw and watertight construction).
It's called a sandbox. Assuming you trust HonestThief, they can write their software such that it safely execute the code of their clients. This approach can cut down on effective CPU throughput (think: Java) if it's not done right.
Note that access to most resources (printer, screen, network, etc.) isn't necessary for the computations that HonestThief's client's code would be doing. They might provide a disk cache of some sort, or even an API to pass messages back out to the network to other processing nodes. I dunno.
Of course, even trusting that HonestThief does write the daemon with an eye towards security and sandboxing, it will be hard for them to get it right on their first try (whether they're pre-verifying the opcodes or using a full blown java-esque approach).
However, this doesn't really matter in the end: big clients spending lots of money on processing power have better things to do than to write virii for which they will go to jail. The biggest danger would be from criminals who subvert the program (prehaps by masquerading as HonestThief.com?).
This argument is particuraly weak: suppose Bob dies (or gets disfigured) in a wreck because some dumb drunk got behind the wheel. It's not Bob's fault, legally or socially. But that doesn't matter to evolution. Without medical interferrance, people with genes like Bob's would have lower survival rates than people who had (1) quicker reaction times, (2) a greater fear of driving at night (especially on the weekends), and/or (3) adamantium skeletons.
That's not to say we shouldn't interfere medically. We all personally want medical attention (as you identified), so we have to be willing to give it to everybody else. Arguments that we should "let evolution take its course" have historically failed (with the result that their promulagators have been portrayed as villians). And maybe there's nothing wrong with basic human compassion: prehaps the way it holds us together as a society does more for survivability than fretting over how many children welfare mothers give birth to.
What will happen to the human race? Don't know, but intelligence isn't all its drummed up to be. Bring on the face transplants: this is just the beginning of what we will do to our biology...