I agree that in many cases a simple call to abort() is insufficient. Obviously you don't want to lose user data. But of cousre these things are configurable. The library could use its own custom assert() that expands to a call to a function pointer which is set by default to abort() (or something more appropritate for the library) and which can be reassigned by the library user, who can then do whatever he wants in the event that the library code breaks down. That should provide enough choice to everyone.
(My apologies for referring specifically to "abort();" when I should have said "foolib_assertion_failure_handler_ptr(); return;".)
My main point is that, as much as will be allowed by requirements, you don't want to try to press on after the program is broken. Save data? Sure. Tell other threads to attempt a graceful shutdown? Fine. Give the user the option to continue anyway? Well, ok, if that's what they requested.
As I read through some of the posts again, I realized that the "fail first" arguments that people made about assert() did not mention asserts in library code. So here's my argument: If an assertion fails, it means the program -- libraries and all -- is in a broken state. If you try to continue normal execution, Bad Things could happen. Data could be lost or corrupted.
As for proper uses of exceptions: Yes, it separates the point of error from the point that can actually try to recover from the error. But unless requirements dictate otherwise, you don't want to throw for errors that represent bugs because if you do, you're going to lose stack information and class objects, and that makes debugging hard (if not impossible). Optionally of course, you could set the handler to give the developer a choice ("Halt? Attempt graceful shutdown? Continue as if nothing happened? Enter debugger?"), so that if you/really/ want to let a broken program try to continue normal execution, you can do so. But I don't see why that should be your first inclination, because it's obvious that stack unwinding makes it harder to isolate the cause of a bug. (But of course you didn't say that's your/first/ inclination; merely that you want the choice, which is perfectly reasonable.)
I suspect that we pretty much agree on this; it's just that we have different expectations about the interfaces for code that reacts to error conditions. Personally I prefer the notion of a handler callback (abort() by default) because, like with exceptions, it reduces the need for error checking code on the client side; also, that makes it easier to make sure that the "Right Thing" (whatever that means in the context of your application) happens in the event of a library bug.
Well, nothing, I suppose, but why would you ever want to use the one that kills your app when some internal test fails?
So that you can isolate a test case and send it to the library vendor so that they can fix it.
If you're talking about NDEBUG, presumably we're in the world of C and/or C++ here. In that case, surely it would be much better for libraries to at least return a proper error code if something goes seriously wrong
Maybe, but, for the library user, I don't see how that's better than an assertion. The point of defining NDEBUG is to remove the runtime overhead of assertion checking. If you replace "if(/*test*/) abort();" with "if(/*test*/) { set_error_code(); return;}", you're still paying the runtime price with no added benefit for the end user. Now, there are cases where a user could legitimately try to recover from a broken state, but generally it's better to halt. Other posters in this thread have done a good job of explaining some of the reasons for that.
or (for C++ libraries) to throw an exception, a tool practically tailor-made for this situation?
If an assertion failure occurs, it means the program is broken. Assuming the programmer does not want to recover from a broken state (which is common), the legitimate uses of exceptions are in/exceptional/ cases that do not really indicate a bug. For example, if a desktop application calls operator new() and the OS cannot allocate enough memory, std::bad_alloc is (usually) thrown.
Perhaps, but no library code should ever cause the whole application to abort, ever.
So what stops a library vendor from shipping two binaries -- one with NDEBUG defined and the other without? The library user would then be able to decide at link time whether to use the library's internal assertions, which she might choose to do if she suspects a bug in the library.
"The iPod, PowerBooks and mini Macs are cool products," Turner said. "The by-product is that people are buying these products for form over function. They say it looks pretty and then buy it but don't secure it."
In all probability, the anti-virus people are not targeting consumers who (for example) choose passwords wisely and make sure that nonessential network services aren't running and don't start up automatically.
They're targeting consumers who have little motivation to understand much more than "point-and-click". That being the case, I don't think the article is necessarily an instance of FUD-spreading.
I was perplexed why anyone would disagree with the following statement:
"A feature will be implemented if and only if there is a developer who wants to implement it"
Because the statement was made within the context of a project that purports to have a 'users first' philosophy . The statement you quoted indicates more of a 'developers first' philosophy. So I guess the whole article boils down to a claim of false advertising.
Your argument against OSX hold against linux/BSD/whatever open source OS. As soon as the number of users reaches critical mass, it becomes "profitable" for virus writes.
Yeah, whatever.
You don't really expect the unix market share to reach the so-called "critical mass" anytime soon, do you? So even if you're right, the open Unixes are still more secure. Make your argument again when OS X hits that "critical mass".
PHP/MIT/BSD et al licences are free as in free time, meaning "no (or few) strings attached".
Oh, but the PHP license *does* come with a string attached: if you use PHP, then you are also using the Zend Engine, which is licensed under the Zend license. There are a couple of interesting notes about it here:
http://www.php.net/license/
Seems to me like it's more restrictive than the GPL. Is it fair for the PHP community to expect MySQL AB to release their library under a less restrictive license when Zend refuses to do the same?
True, nobody took anything away from you, but look at it this way: you lost out on some cash. You could have released the code in a dual-licence way, like Hans Reiser does. I.e., make it freely available under the GPL, and charge some amount of money for less restrictive licenses. That way companies that like to charge ridiculous sums for closed-source software would be happy and your bank account will be healthier.
Here's what makes BSD (and its ilk) freaky: You may hold the copyright on your BSD-licenced work, but it doesn't matter unless you get off on seeing your name on boxed products (due to the Advertisement Clause, which is not present in more recent forms). It really might as well be Public Domain.
On the other hand, if you release code under the terms of the GPL, you (the copyright holder) still maintain some control over it. And it's certainly less restrictive than the Zend license (which is not to be confused with the PHP license -- but if you're using one, you're pretty much locked into the other). For example, the GPL allows you to sell software that links to glibc. Want to try the same with software that links to the Zend library? Expect to hear from a lawyer. Doesn't sound all that "free", does it? Is it fair for the PHP community to expect MySQL AB to make their library available under a less restrictive license when Zend is unwilling to do the same?
But I digress...back to the GPL vs. BSD issue: yes, BSD might be better if you want as many people as possible to potentially use some fragment of what you wrote. But the GPL will keep you from getting ripped off. It lets you make Fair Software.
So I guess it comes down to a matter of personal choice: i.e., how much you think your software is worth, etc. Personally, if I wrote something that Microsoft could legally distribute in binary-only form, and if all I got in return was my name in the fine print somewhere, I'd kick myself. But that's just me.
Though personally I am of the opinion that "M$ iz teh sux0r!", I nonetheless found the first edition to be full of insights and advice that authors of Free Software would do well to heed. McConnell r0x0rs. Buy the second edition from B&N.
I've always figured that it was up to the record labels how they distributed music.
It is.
I don't see how Fair Rights and the First Amendment really come into play here.
Well, they don't come into play (with respect to music distribution). Sorry, I was trying to make two points at once, and thus (evidently) introduced some confusion, which I'll try to clear up now.
First, on Fair Use: understand that the intent behind the DMCA is to make it possible for Apple (and other companies) to nullify your Fair Use rights. The point is this: if you don't have the ability to download a program like Hymn, then you'll have no way to break the DRM. If you are unable to break the DRM, then you cannot fully exercise your Fair Use rights. See, they didn't make Fair Use illegal. It's just that they're trying to make Fair Use impossible. They're doing it by trampling on the First Amendment rights of the people who made Hymn. How are they doing that? Well, understand that program source code is a form of speech. But Apple says that they don't like this particular kind of speech (the kind that tells other programmers how to break DRM). And what's more, the DMCA agrees with Apple. So if the program is being distributed from within the U.S.A., Apple gets its way and the programmer is silenced. This is exactly what happened when Apple sent a Cease and Desist letter (citing the DMCA) to SourceForge.net. [Note: there's nothing wrong with the DRM itself. The problem is that, because of the DMCA, I'm not allowed to tell you how to break Apple's DRM. In other words, it's illegal for me to help my neighbor fully exercise his/her rights.]
Second, on distribution: Yes, the recording industry can distribute music however it wants. But in the future, it will probably distribute *more* music online because it makes economic sense to do so: the market is there and the costs are lower. Therefore, it's quite likely that in the future they'll make more money from that than they presently make from CD sales. The point is this: Apple and the RIAA companies aren't exactly starving. They've made a lot of profits and they will make a lot more in the future. So don't speak of their form of online distribution as if it's a charity that requires your "support". Similarly, don't speak as if there are no alternatives in the market. They're doing just fine even though (or perhaps in part *because*) anyone can download and use Hymn.
[Side note: independent artists on the other hand *should* get your support if you really like their music.]
Doesn't the content owner have the right to dictate how that content is bought and sold. After all, music is not an essential service, and people can simply choose not to buy it if they don't agree with how it's being distributed.
If you really think that it's a non-essential service, then why are you willing to give up your right to Free Speech for it? I refer to this comment you made earlier: "...I don't think it's fair for people to jeopardize my ability to buy online music." The rights of the author of Hymn are also your rights. You should not dismiss the rights of others just because you think that their freedom makes your life more inconvenient.
People don't need to by from the iTunes Music store, if they want music to play on a non-Apple mp3 player, they should just buy it elsewhere.
Well, thanks to the fact that citizens of India enjoy more freedom than Americans do (in this case), there's no need to do that. An American can buy a track from iTunes and then download Hymn (from a web server located in India). But this issue still matters for a few reasons: first, we shouldn't have to go outside of the country (as the Hymn people had to, and as each user of Hymn must now do) to get back the freedoms we lost in 1998 (when the DMCA was passed). Second, it's the principle of the thing: Apple and the R
I think it's pretty clear that Apple is anti-open source (and in this case anti-Free Software) when the distribution of some project makes life inconvenient for them.
They Hymn project will not jeopardize the availability of online music. It makes more business sense to distribute online (if your customers are online) because the cost of doing so is much lower than distributing on CD. Online music does not need your support; there is a healthy demand for it. There will be (and are today) many suppliers of online music besides Apple. And no matter what happens, I'm sure Apple will find a way to make it profitable.
Apple should do everything in their power to prevent the breaking of their DRM because their contracts with record labels obligates them to do so.
I think this is the point where we disagree: you say their contract should always dictate their actions. I say they are obligated to get out of or break their contracts when the actions dictated by the contract are unethical.
Can I seriously expect them to do that on their own? Well, certainly not in this case. Apple, alongside other companies, lobbied very hard to get the DMCA passed into law. They're not doing this stuff just because the RIAA says so. They're doing it because they really don't care about your Fair Use rights or the First Amendment rights of the Hymn project people. All they can see is that they've lost some control over the execution of the business model and that they can put someone behind bars for it if they ever find his identity.
I really wish that was not the case, because if it weren't for its history of taking the ethically incorrect path on this and so many other issues, Apple would be my favorite tech company. It's really annoying that there is so much to love and simultaneously so much to hate about what that company does.
Some how, I think the Play Fair guys should have had some inkling in advance that this was going to happen.
Of course the PlayFair guys (now known as the Hymn guys) were well aware that Apple would serve papers citing the DMCA. That's not the point.
Or do you seriously think Apple shouldn't do anything about people breaking their DRM scheme?
Apple *should* do something when people break their DRM scheme. They should come up with a better DRM scheme. They should *NOT* try to pass and enforce laws that take away freedoms (note that in certain cases, the DMCA has the effect of direcly nullifying the First Amendment and indirectly nullifying Fair Use rights).
After all, it is the only way they could get labels to sign on to the iTunes music store.
So unethical practices should be tolerated so long as those practices result in business relationships being built or maintained?
It is lawful to enforce the DMCA. But it is wrong to do so. It's a sign of ethical corruption. The DMCA needs to be repealed, and companies like Apple want to keep that from happening.
If someone wrote an open source computer virus for the mac, would you still cry foul when apple tries to shut them down? Just because something's open source, doesn't make it good.
Viruses are created with malicious intent and can cause side effects that are clearly harmful. The creators of Hymn have no malicious intent and the program itself causes no damage to the system of any user who runs it.
Furthermore, Hymn is a good program because it allows users to exercise their Fair Use rights which were granted to them by copyright law. Its distribution is an instance of free speech being exercised. There is nothing bad about it. True, it may make life inconvenient for the RIAA. But that's their problem. Given that the program is being distributed from India, it is impossible for the distribution or the use of Hymn to result in the transgression of any law. So I think it's a little unfair for you to speak of Hymn as if it could be compared to a virus.
Please clarify your position. What exactly is bad about Hymn? Why is it bad to exercise Fair Use rights? Why should the RIAA and Apple and other large corporations be allowed to forbid us from taking actions that break no law (save, possibly, the DMCA) and have nothing to do with copyright infringement?
Yeah. If it's not in the filesystem, then it just shouldn't be done at all -- mainly (IMHO) because of The Filename Lie that would otherwise arise: Imagine the Chinese-only speaker trying to do some command line operation on an entry, only to get "file not found". So he has to find out the English word for that entry and type *that* in.
It would be like "C:\PROGRA~1" all over again. And we know what to do with *that* kind of crap, don't we? That's right: whip out an *intelligent* distro's install CD and have an fdisk fest.:-)
1) The thing is that filesystems present an interface. So, yes, it's definitely an interface issue, but that doesn't mean we shouldn't consider fixing the filesystem. (You probably meant to say that it's a *user* interface issue, but that is by no means the only kind of interface that should be examined.)
2) If we expect other programs to do the translations, then we need to implement the translation feature several times, i.e., for everything that wants to use the localized text. If it's implemented in the filesystem, everything else can take advantage of it without any change (or with fewer changes).
Besides, if other tools like shells try to do translations like this, they'll be lying: the directory entry wouldn't really have a localized name. But if it's built into the filesystem, the entry could have several names, and the current one would depend on some setting; the entry could also be referred to using any of its localized names and an argument that specifies the name's locale.
Of course, it would probably be silly to try to implement this with anything other than Reiser4 -- mainly because adding this localization feature wouldn't require any change to the Reiser4 codebase itself (i.e., it would just be another plugin).
Not sure if this is a good idea, but here it goes:
Directory entries could be presented to the user in his/her native language after the fashion of gettext -- i.e., the language/locale of the text would be determined by some environment variable, configuration setting, or command issued by the user.
Imagine a user who speaks only Mandarin Chinese. Suppose he gets a list of directory entries at the root level. There he would see the Chinese words for "System", "Applications", "Library", etc.
Later, when an English-only speaker uses the same machine, he'll see the same directory names in English, either because:
1) He logged into his own account, which is set so that the OS presents everything, including directory entries, in his language and locale, or: 2) He issued some command to change the language during the same session with the same account.
Normally, this would be difficult to implement (and have it work everywhere in the operating system -- not just while in a special desktop environment). But maybe Reiser4, with its plugin architecture, will allow the job to be done with a small amount of effort; see here:
1) Unless you encrypt them, your emails are not private. No encryption == no privacy. It's that simple. The ignorance of the masses regarding this fact does not make it any less true.
2) The internet is far more transparent (and is far more scannable by the common man) than the phone system. See (1).
3) Laws like this have a way of coming back to bite us in the ass. Suppose you want your emails scanned and routinely data-mined, for example. In such a case, there is no victim, so what good is the law?
I'm ok with laws that say that companies must make their privacy policies publicly readable, but laws that/dictate/ those policies will have ill effect sooner or later.
Without encryption, everything we send via email is essentially world-readable anyway.
To suggest that the passing of this legislation will help to keep GMail's user's communications private is like saying that invading Iraq helped the U.S. government in its fight against terrorism.
If they/really/ wanted to help the common man keep his emails from prying eyes, they'd start a program to fund OSS development to help make OpenPGP software more easily accessible and usable.
But that's not something California should be dumping resources into right now anyway.
$851 is AMD's official price for boxed CPUs for distributors, not consumers -- that is, it's priced for customers who buy 1,000 CPUs at a time (though you can also get single OEM CPUs at about that price from other vendors).
Also note that Monarch is pretty much AMD's top distributor for boxed CPUs. They sell it for $900, which seems like a reasonable markup.
But yeah, the $970 price tag from Computers4Sure is probably due to short supply. But I don't know why anyone would buy it at that price. I mean, we have Froogle, fer cryin' out loud.:)
It was an episode in the first season. The ship's token Vulcan sent an encrypted private message to her parents. The human crew found it suspicious that the message was encrypted, so one of the officers "just" decrypted it.
Drink that in. Puny humans flick a switch and break strong encryption created by Vulcans.
Ok, so let's go on the assumption that all encryption is weak in the future. Suppose they have computers that break all kinds of inconvenient laws of physics in order to nullify the effects of all public key-style encryption. And suppose that the all-logical ('cept on those rare Pam Far days) Vulcans, in spite of this awareness, do not opt to use one-time pads for secure communication.
...
Yeah. Doesn't work. I know it's just a show, but it's not like MST3K: they're trying to be serious. It irked me. I stopped watching, anticipating more crap like that.
Speaking of Zelda, anyone remember the old Zelda cartoons that we had on TV once? That's a classic example of what I'm talking about; those cartoons made my eyes bleed. Badly.
...with horrible lines like, "well excuuuuuuse me, princess," how can we forget?:-)
Remember kids: only Steve Martin should impersonate Steve Martin.
Heh....now, if they made Zelda into a live-action comedy with Steve Martin as a royal retainer....that line might actually work.:-)
Good god, people, the creator of the language deserves better than a score of 1---especially when he's counter-attacking a piece of FUD that got way over-modded.
Further discussion on memory management as it relates to D can be found here.
A slick, responsive 3D fighter game written in D (and somehow unencumbered by the burden placed on it by the garbage collector) can be found here. Source included, so you can see how slick it is on the inside.
And Walter: Thank you. I've spent a lot of time reading and interpreting the ISO C++ standard, and it usually leaves my brain feeling itchy, flaky, and swollen. With that in mind, I'd just like to say that, after reading all the specs I could find, D (so far) seems to me like the Gold Bond Medicated Powder of programming languages.:-)
While viewing the page for this article, I spotted a clear example of "wrong behavior". So, under Safari's "Safari" menu, I clicked on "Report bugs to Apple", and selected from the pull-down menu "Wrong behavior," with a calm explanation that the DMCA is unconstitutional and therefore should only be attacked in court, not supported.
I would encourage anyone out there with a Mac to do the same.
Not quite. You're thinking of the all-package-files-under-one-package-directory model. That's cool, and that's in OS X, but that's only *part* of ZI. But an example is worth a thousand flames. See here:
Granted, the way you experience the download-open-run business on OS X is close, but the beauty is that because of the use of NFS, a remote directory (perhaps mounted under a directory like/Applications), looks like a local one. The real advantage is only slight in that you've only saved yourself the process of dragging the.app dir from some mounted DMG to/Applications---assuming Safari is set to have DMGs opened and mounted by default, it's admittedly not a huge gain in terms of usability. But still. With a smidge more automation, you would only have to click on a link in a web browser, and after a minute or so, without any other user intervention, the.app is up and running.
Aditionally, they could make it so web browsing isn't necessary in many cases. An NFS directory entry provided by Adobe could be mounted under/Applications by default for example. You browse into/Applications/Adobe. Since Adobe/ is really an NFS share, new stuff just pops in there whenever Adobe comes out with anything new. You double click on "Photoshop" and an evaluation version of Photoshop starts up (after being cached from adobe.com). Later you decide to keep it, punch in the serial number, and all the other features activate. When you're offline, the latest cached version is used. When you're online and you run it, the ZI system looks for a more up-to-date point release and downloads it automatically.
Hear hear (though I'm sure their UI people are already aware of it---ZI has been in development for a while now). Certainly commercial app developers should like it because it gives the user a very easy way to try the "trial version". This would lead to more trials, presumably meaning more sales. It goes without saying that Free Software people should like it just from a usability standpoint.
The only way it could *suck* is if Microsoft is the first company to use it in a big way.
Slashdot Mirror
I agree that in many cases a simple call to abort() is insufficient. Obviously you don't want to lose user data. But of cousre these things are configurable. The library could use its own custom assert() that expands to a call to a function pointer which is set by default to abort() (or something more appropritate for the library) and which can be reassigned by the library user, who can then do whatever he wants in the event that the library code breaks down. That should provide enough choice to everyone.
/really/ want to let a broken program try to continue normal execution, you can do so. But I don't see why that should be your first inclination, because it's obvious that stack unwinding makes it harder to isolate the cause of a bug. (But of course you didn't say that's your /first/ inclination; merely that you want the choice, which is perfectly reasonable.)
(My apologies for referring specifically to "abort();" when I should have said "foolib_assertion_failure_handler_ptr(); return;".)
My main point is that, as much as will be allowed by requirements, you don't want to try to press on after the program is broken. Save data? Sure. Tell other threads to attempt a graceful shutdown? Fine. Give the user the option to continue anyway? Well, ok, if that's what they requested.
As I read through some of the posts again, I realized that the "fail first" arguments that people made about assert() did not mention asserts in library code. So here's my argument: If an assertion fails, it means the program -- libraries and all -- is in a broken state. If you try to continue normal execution, Bad Things could happen. Data could be lost or corrupted.
As for proper uses of exceptions: Yes, it separates the point of error from the point that can actually try to recover from the error. But unless requirements dictate otherwise, you don't want to throw for errors that represent bugs because if you do, you're going to lose stack information and class objects, and that makes debugging hard (if not impossible). Optionally of course, you could set the handler to give the developer a choice ("Halt? Attempt graceful shutdown? Continue as if nothing happened? Enter debugger?"), so that if you
I suspect that we pretty much agree on this; it's just that we have different expectations about the interfaces for code that reacts to error conditions. Personally I prefer the notion of a handler callback (abort() by default) because, like with exceptions, it reduces the need for error checking code on the client side; also, that makes it easier to make sure that the "Right Thing" (whatever that means in the context of your application) happens in the event of a library bug.
They're targeting consumers who have little motivation to understand much more than "point-and-click". That being the case, I don't think the article is necessarily an instance of FUD-spreading.
You don't really expect the unix market share to reach the so-called "critical mass" anytime soon, do you? So even if you're right, the open Unixes are still more secure. Make your argument again when OS X hits that "critical mass".
True, nobody took anything away from you, but look at it this way: you lost out on some cash. You could have released the code in a dual-licence way, like Hans Reiser does. I.e., make it freely available under the GPL, and charge some amount of money for less restrictive licenses. That way companies that like to charge ridiculous sums for closed-source software would be happy and your bank account will be healthier.
Here's what makes BSD (and its ilk) freaky: You may hold the copyright on your BSD-licenced work, but it doesn't matter unless you get off on seeing your name on boxed products (due to the Advertisement Clause, which is not present in more recent forms). It really might as well be Public Domain.
On the other hand, if you release code under the terms of the GPL, you (the copyright holder) still maintain some control over it. And it's certainly less restrictive than the Zend license (which is not to be confused with the PHP license -- but if you're using one, you're pretty much locked into the other). For example, the GPL allows you to sell software that links to glibc. Want to try the same with software that links to the Zend library? Expect to hear from a lawyer. Doesn't sound all that "free", does it? Is it fair for the PHP community to expect MySQL AB to make their library available under a less restrictive license when Zend is unwilling to do the same?
But I digress...back to the GPL vs. BSD issue: yes, BSD might be better if you want as many people as possible to potentially use some fragment of what you wrote. But the GPL will keep you from getting ripped off. It lets you make Fair Software.
So I guess it comes down to a matter of personal choice: i.e., how much you think your software is worth, etc. Personally, if I wrote something that Microsoft could legally distribute in binary-only form, and if all I got in return was my name in the fine print somewhere, I'd kick myself. But that's just me.
Though personally I am of the opinion that "M$ iz teh sux0r!", I nonetheless found the first edition to be full of insights and advice that authors of Free Software would do well to heed. McConnell r0x0rs. Buy the second edition from B&N.
It is.
Well, they don't come into play (with respect to music distribution). Sorry, I was trying to make two points at once, and thus (evidently) introduced some confusion, which I'll try to clear up now.
First, on Fair Use: understand that the intent behind the DMCA is to make it possible for Apple (and other companies) to nullify your Fair Use rights. The point is this: if you don't have the ability to download a program like Hymn, then you'll have no way to break the DRM. If you are unable to break the DRM, then you cannot fully exercise your Fair Use rights. See, they didn't make Fair Use illegal. It's just that they're trying to make Fair Use impossible. They're doing it by trampling on the First Amendment rights of the people who made Hymn. How are they doing that? Well, understand that program source code is a form of speech. But Apple says that they don't like this particular kind of speech (the kind that tells other programmers how to break DRM). And what's more, the DMCA agrees with Apple. So if the program is being distributed from within the U.S.A., Apple gets its way and the programmer is silenced. This is exactly what happened when Apple sent a Cease and Desist letter (citing the DMCA) to SourceForge.net. [Note: there's nothing wrong with the DRM itself. The problem is that, because of the DMCA, I'm not allowed to tell you how to break Apple's DRM. In other words, it's illegal for me to help my neighbor fully exercise his/her rights.]
Second, on distribution: Yes, the recording industry can distribute music however it wants. But in the future, it will probably distribute *more* music online because it makes economic sense to do so: the market is there and the costs are lower. Therefore, it's quite likely that in the future they'll make more money from that than they presently make from CD sales. The point is this: Apple and the RIAA companies aren't exactly starving. They've made a lot of profits and they will make a lot more in the future. So don't speak of their form of online distribution as if it's a charity that requires your "support". Similarly, don't speak as if there are no alternatives in the market. They're doing just fine even though (or perhaps in part *because*) anyone can download and use Hymn.
[Side note: independent artists on the other hand *should* get your support if you really like their music.]
If you really think that it's a non-essential service, then why are you willing to give up your right to Free Speech for it? I refer to this comment you made earlier: "...I don't think it's fair for people to jeopardize my ability to buy online music." The rights of the author of Hymn are also your rights. You should not dismiss the rights of others just because you think that their freedom makes your life more inconvenient.
Well, thanks to the fact that citizens of India enjoy more freedom than Americans do (in this case), there's no need to do that. An American can buy a track from iTunes and then download Hymn (from a web server located in India). But this issue still matters for a few reasons: first, we shouldn't have to go outside of the country (as the Hymn people had to, and as each user of Hymn must now do) to get back the freedoms we lost in 1998 (when the DMCA was passed). Second, it's the principle of the thing: Apple and the R
They Hymn project will not jeopardize the availability of online music. It makes more business sense to distribute online (if your customers are online) because the cost of doing so is much lower than distributing on CD. Online music does not need your support; there is a healthy demand for it. There will be (and are today) many suppliers of online music besides Apple. And no matter what happens, I'm sure Apple will find a way to make it profitable. I think this is the point where we disagree: you say their contract should always dictate their actions. I say they are obligated to get out of or break their contracts when the actions dictated by the contract are unethical.
Can I seriously expect them to do that on their own? Well, certainly not in this case. Apple, alongside other companies, lobbied very hard to get the DMCA passed into law. They're not doing this stuff just because the RIAA says so. They're doing it because they really don't care about your Fair Use rights or the First Amendment rights of the Hymn project people. All they can see is that they've lost some control over the execution of the business model and that they can put someone behind bars for it if they ever find his identity.
I really wish that was not the case, because if it weren't for its history of taking the ethically incorrect path on this and so many other issues, Apple would be my favorite tech company. It's really annoying that there is so much to love and simultaneously so much to hate about what that company does.
It is lawful to enforce the DMCA. But it is wrong to do so. It's a sign of ethical corruption. The DMCA needs to be repealed, and companies like Apple want to keep that from happening. Viruses are created with malicious intent and can cause side effects that are clearly harmful. The creators of Hymn have no malicious intent and the program itself causes no damage to the system of any user who runs it.
Furthermore, Hymn is a good program because it allows users to exercise their Fair Use rights which were granted to them by copyright law. Its distribution is an instance of free speech being exercised. There is nothing bad about it. True, it may make life inconvenient for the RIAA. But that's their problem. Given that the program is being distributed from India, it is impossible for the distribution or the use of Hymn to result in the transgression of any law. So I think it's a little unfair for you to speak of Hymn as if it could be compared to a virus.
Please clarify your position. What exactly is bad about Hymn? Why is it bad to exercise Fair Use rights? Why should the RIAA and Apple and other large corporations be allowed to forbid us from taking actions that break no law (save, possibly, the DMCA) and have nothing to do with copyright infringement?
Yeah. If it's not in the filesystem, then it just shouldn't be done at all -- mainly (IMHO) because of The Filename Lie that would otherwise arise: Imagine the Chinese-only speaker trying to do some command line operation on an entry, only to get "file not found". So he has to find out the English word for that entry and type *that* in.
:-)
It would be like "C:\PROGRA~1" all over again. And we know what to do with *that* kind of crap, don't we? That's right: whip out an *intelligent* distro's install CD and have an fdisk fest.
1) The thing is that filesystems present an interface. So, yes, it's definitely an interface issue, but that doesn't mean we shouldn't consider fixing the filesystem. (You probably meant to say that it's a *user* interface issue, but that is by no means the only kind of interface that should be examined.)
2) If we expect other programs to do the translations, then we need to implement the translation feature several times, i.e., for everything that wants to use the localized text. If it's implemented in the filesystem, everything else can take advantage of it without any change (or with fewer changes).
Besides, if other tools like shells try to do translations like this, they'll be lying: the directory entry wouldn't really have a localized name. But if it's built into the filesystem, the entry could have several names, and the current one would depend on some setting; the entry could also be referred to using any of its localized names and an argument that specifies the name's locale.
Of course, it would probably be silly to try to implement this with anything other than Reiser4 -- mainly because adding this localization feature wouldn't require any change to the Reiser4 codebase itself (i.e., it would just be another plugin).
Not sure if this is a good idea, but here it goes:
Directory entries could be presented to the user in his/her native language after the fashion of gettext -- i.e., the language/locale of the text would be determined by some environment variable, configuration setting, or command issued by the user.
Imagine a user who speaks only Mandarin Chinese. Suppose he gets a list of directory entries at the root level. There he would see the Chinese words for "System", "Applications", "Library", etc.
Later, when an English-only speaker uses the same machine, he'll see the same directory names in English, either because:
1) He logged into his own account, which is set so that the OS presents everything, including directory entries, in his language and locale, or:
2) He issued some command to change the language during the same session with the same account.
Normally, this would be difficult to implement (and have it work everywhere in the operating system -- not just while in a special desktop environment). But maybe Reiser4, with its plugin architecture, will allow the job to be done with a small amount of effort; see here:
http://www.namesys.com/v4/v4.html
1) Unless you encrypt them, your emails are not private. No encryption == no privacy. It's that simple. The ignorance of the masses regarding this fact does not make it any less true.
/dictate/ those policies will have ill effect sooner or later.
2) The internet is far more transparent (and is far more scannable by the common man) than the phone system. See (1).
3) Laws like this have a way of coming back to bite us in the ass. Suppose you want your emails scanned and routinely data-mined, for example. In such a case, there is no victim, so what good is the law?
I'm ok with laws that say that companies must make their privacy policies publicly readable, but laws that
Seriously.
/really/ wanted to help the common man keep his emails from prying eyes, they'd start a program to fund OSS development to help make OpenPGP software more easily accessible and usable.
Without encryption, everything we send via email is essentially world-readable anyway.
To suggest that the passing of this legislation will help to keep GMail's user's communications private is like saying that invading Iraq helped the U.S. government in its fight against terrorism.
If they
But that's not something California should be dumping resources into right now anyway.
$851 is AMD's official price for boxed CPUs for distributors, not consumers -- that is, it's priced for customers who buy 1,000 CPUs at a time (though you can also get single OEM CPUs at about that price from other vendors).
:)
Also note that Monarch is pretty much AMD's top distributor for boxed CPUs. They sell it for $900, which seems like a reasonable markup.
But yeah, the $970 price tag from Computers4Sure is probably due to short supply. But I don't know why anyone would buy it at that price. I mean, we have Froogle, fer cryin' out loud.
It was an episode in the first season. The ship's token Vulcan sent an encrypted private message to her parents. The human crew found it suspicious that the message was encrypted, so one of the officers "just" decrypted it.
Drink that in. Puny humans flick a switch and break strong encryption created by Vulcans.
Ok, so let's go on the assumption that all encryption is weak in the future. Suppose they have computers that break all kinds of inconvenient laws of physics in order to nullify the effects of all public key-style encryption. And suppose that the all-logical ('cept on those rare Pam Far days) Vulcans, in spite of this awareness, do not opt to use one-time pads for secure communication.
...
Yeah. Doesn't work. I know it's just a show, but it's not like MST3K: they're trying to be serious. It irked me. I stopped watching, anticipating more crap like that.
Speaking of Zelda, anyone remember the old Zelda cartoons that we had on TV once? That's a classic example of what I'm talking about; those cartoons made my eyes bleed. Badly.
...with horrible lines like, "well excuuuuuuse me, princess," how can we forget? :-)
:-)
Remember kids: only Steve Martin should impersonate Steve Martin.
Heh....now, if they made Zelda into a live-action comedy with Steve Martin as a royal retainer....that line might actually work.
Good god, people, the creator of the language deserves better than a score of 1---especially when he's counter-attacking a piece of FUD that got way over-modded.
:-)
Further discussion on memory management as it relates to D can be found here.
A slick, responsive 3D fighter game written in D (and somehow unencumbered by the burden placed on it by the garbage collector) can be found here. Source included, so you can see how slick it is on the inside.
And Walter: Thank you. I've spent a lot of time reading and interpreting the ISO C++ standard, and it usually leaves my brain feeling itchy, flaky, and swollen. With that in mind, I'd just like to say that, after reading all the specs I could find, D (so far) seems to me like the Gold Bond Medicated Powder of programming languages.
While viewing the page for this article, I spotted a clear example of "wrong behavior". So, under Safari's "Safari" menu, I clicked on "Report bugs to Apple", and selected from the pull-down menu "Wrong behavior," with a calm explanation that the DMCA is unconstitutional and therefore should only be attacked in court, not supported.
I would encourage anyone out there with a Mac to do the same.
Not quite. You're thinking of the all-package-files-under-one-package-directory model. That's cool, and that's in OS X, but that's only *part* of ZI. But an example is worth a thousand flames. See here:
http://zero-install.sourceforge.net
Granted, the way you experience the download-open-run business on OS X is close, but the beauty is that because of the use of NFS, a remote directory (perhaps mounted under a directory like
Aditionally, they could make it so web browsing isn't necessary in many cases. An NFS directory entry provided by Adobe could be mounted under
AFAIK, OS X does not have that....*yet*.
Hear hear (though I'm sure their UI people are already aware of it---ZI has been in development for a while now). Certainly commercial app developers should like it because it gives the user a very easy way to try the "trial version". This would lead to more trials, presumably meaning more sales. It goes without saying that Free Software people should like it just from a usability standpoint.
The only way it could *suck* is if Microsoft is the first company to use it in a big way.
In the split second before I realized it was AFD, I thought "Holy carp! He's going to compete with us!"
:-)
/me waits to be modded into oblivion.
Then I thought, "Waitaminute...remember Emacs?" Then I relaxed...