Somehow people seem to think that medicine comes from some magic wand that costs nothing to wave so we can have infinite research, development, production, etc. for zero or nominal cost.
Nobody thinks that drugs should be free. They do think they could be made a lot cheaper than they are. And it'd be a lot more convincing when the pharamaceuticals deny this if they weren't spending twice as much on marketing as on R&D.
I mean, really, doesn't it seem a little off to be complaining of being crushed by one expense when there's another 2 1/2 times bigger?
Why are most of those drugs developed here and not in France, Mexico, or even Japan? Or even Canada? Canada is free to spend more on its health care developing its own drugs (will THEY give them to the US for free or below cost?).
Because we have the most developed pharmaceutical industry. Is that because we pump the most dollars into our medical care? Or is it because of the benefits of this country's tech industry? Or is it because of our higher education system producing the best engineers? Or is it because free trade with us means no Canada-only pharmaceuticals can get a grip there? You may as well ask why Canada doesn't produce as many cars. You haven't show cause and effect.
Meanwhile, our military does protect Canada, while it lets in terrorists and even gives them welfare so they have more time to figure out ways of killing US Citizens.
Protects Canada from whom? I'd like to point out that all these terrorists manage to make it the whole way through Canada without blowing anything up. Canada isn't their target. We're protecting nobody but ourselves.
And besides, we give our terrorists green cards even after they've commited acts of terror, so who are we to point fingers?;)
Personally, I think we should not be an empire, but if we are, our "friends" should recognize what it means to them.
What are you even saying here? Are you saying that Canada should be grateful for us being an empire that we shouldn't be if in fact we are?
For anyone boggling at how much Canada spends on health care (and realizing that 30% isn't the correct figure), you should know that here in the U.S. we spend roughly twice as much per-capita as the Canadians on health care (through insurance premiums, instead of taxes). The problem is that our system is so bogged down in inefficiency, that we're losing 50 cents on the dollar to middlemen. If we cut out the middlemen and maintained the same level of spending, we'd have a health system that'd put the Canadians to shame. And isn't that what it's all about?:)
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
Well, not exactly... What we're saying is that all the faults in useability/functionality that you may have been able to say X had are slowly and surely being whacked out. That they happen without disruption at all in compatability is a sign that there is no fundamental reason for these flaws, they are simply there because they haven't been done yet.
True, but when Windows Terminal Server came out, that takes a back seat. Try running an X11 session over a slow network link vs. a Windows terminal server session (especially over Citrix ICA) and let me know how it goes.
Depends... are we running it through ssh, telnet, or vnc? Vnc sessions are about as snappy as TS (minus the unfortunate remotely-rendered mouse of vnc). Of course Vnc suffers from the same advantage as TS, which is that it can render everything locally and compress and transmit the results.
But certainly X could use improvement in this area. That doesn't mean it won't come, or that we need to -start over-. It could be as simple as another extension.
It's not copyright extension that is the issue. While it may be true that extensions should be carefully considered as to whether they do attack the first clause, it isn't being generalized that they -all- are.
No, what is considered an attack on the first clause is retroactive extensions. Retroactive extensions are the mechanism for having perpetual copyright.
This new, improved economic system is called "authoritarian capitalism", and is unique in that it pleases both Rand capitalists and Marx socialists, but for different reasons.
The best one-sentence description of everything wrong with the modern notion of capitalism I've ever heard.
Though it scares me a little -- I shudder to think of the chance that, a hundred years from now, Ayn Rand and Karl Marx will be mentioned together.:P
I have yet to see anyone explain the true privacy concern of a roving wiretap.
Then you haven't been paying attention. It's been done again and again.
And frankly, if you can't think of it yourself, then you're not trying very hard.
And John Ashcroft passed nothing. He doesn't want other, random people to have your info. He wants it himself. That's why he doesn't let civilians perform roving wiretaps.:P
This results in being able to move back and forth in time, but not being able to move away from the center of the black hole.
Really? I've never heard that before! I'm not a physicist, so I'm just talking about things that come up in common places.:)
But that's really cool. So, all you need to do is find a device that can make -itself- travel through time, and you could travel into the black hole, move yourself through time, and then use the device to move yourself out of the black hole . You've go yourself a method of time travel!
I'm of course somehow assuming it's easier to make a device that can travel through time without taking a person with it.
And that you can somehow get into the black hole alive.
No, my proposed system and Palladium are similiar in that they only "trusted" components are the nub, nexus, and fritz chip. The kernel is *not trusted*.
This is not the impression of Palladium I've gotten from the documentation. I've got someone I can ask who would know for certain, so I'll do that.:)
Wrong. There is not a large body of digital content to play. You cant by and large get movies. You cant by and large get legal digital music. You cant by and large dowload digital books, blah blah blah. With a secure infrastructure in place you could. Your options for digital downloads of digital data would increase 10, 100, or 1000 fold. Thats a feature.
That is what the media providers keep telling us. But is the reason because they are slow to adapt new technologies, because they would rather have Palladium and are waiting for it, or because they fundamentally would not offer content without Palladium? It is not clear that, should it become the case that Palladium is soundly rejected by the populace at large, the media companies wouldn't offer digital content regardless, so as not to be left behind.
The only feature what you can claim is getting more content. But the only thing what you suggest actually does is provide content I do get with enforced restrictions. Whether that actually is a necessary and sufficient condition for the production of that content is unclear.
And it is in fact quite possible to get legal digital music. I have several gigs of good mp3's downloaded from Emusic.com. I paid for them. Clearly there are those willing to fill in the space left by major media's reluctance to enter the digital realm without a digital police officer watching our every move.
Wrong, the rapant copyright infringement we have now is what prevents you from having a lot of digital content on your desktop. Thats the stopping point.
Wrong. What prevents me from having a lot of digital content (discount my gigs of legal music for the moment) is the providers' decision not to offer it. There reason for that decision may be piracy, but they certainly do not have to make that decision. Evidence points to the possibility that piracy effects them not at all negatively, perhaps even positively. Makers of video games haven't stopped producing "digital content" because of the lack of Palladium, and they are still doing well enough for themselves. Some, like Bioware, have stopped copy protecting their games at all.
Digital content is a young market. You can no more say that the lack of digital content is the fault of piracy than I can say it's the lack of sufficient broadband capabilities to make digital content appealing to consumers. But clearly there is digital content without Palladium, and the amount of content is increasing.
So it's not inevitable at all that we can't have digital content without Palladium. The question is whether we should go to all this trouble just to make a couple of providers feel comfortable. If we say "no, we won't do that", then those providers will either give in, or be made irrelevent by providers who will. It's not like we have to get our digital content from MGM Studios or else it doesn't count, right?
No, thats not we are discussing. Thats what you are discussing. I am discussing whether a DRM system can be built without relying on security-through-obscurity.
Originally, yes. But you claimed this also was FSF friendly, and I disuputed that, and you rebutted. The topic of discussion shifted to encompass that. That happens in discussions, you know. Of course, I said we weren't discussing the "should" question, but then we discussed that, too. Eh.
Okay, you need a primer in how a system like Palladium would probably work.
System like Palladium. Stop calling it Palladium then, because that isn't what you are talking about.
The hardware chip, lets call him fritz, can be instructed to do stuff: like load code into the secure area of the system.
And where does the fritz chip get this code? Does it understand file systems, network protocols, and memory management? In other words, once it does what it would have to in order to eliminate the need for a secure OS, what need have you left for an OS at all?
So your claim that Palladium "absolutely needs a trusted trusted kernel" is false. You can pretend like you know what you are talking about. But you are wrong. It is simply untrue. Not true. Okay, not true.
But on Palladium, it is true. That is how this system is designed to work. Palladium requires a secure kernel. Your proposed system may not, but you didn't make it clear you were talking about a hypothetical system. Call it Rhodium or something, if you want to be clear.
But yes, I understand, Rhodium doesn't require a trusted kernel.
If you want to call it faux freedom, thats fine. We are reading each other completely on this, it seems to be a fundamental disagreement of what free is.
I'm going by the same definition the FSF uses. You claimed your idea was in accordance with this. It is not. That's all I'm really saying here, as far as the issue of freedom goes.
On top of that, what I described upholds the core traits of open source software - the ability to see the source. It does not uphoad the all core traits of the FSF, but the largest majority of them.
Your grasp of the core traits of the FSF is innacurate. If all they cared about was being able to see the source, then Microsoft's Shared Source would be considered free software. It isn't, because it's not. Your proposal allows little better.
it accomodates OSS code and to a much lesser degree FSF code,
Yes, good to see you backing off on that one. You've got a decent system here, with more to offer than what they currently are, at least in terms of giving us back what we already have. And no, "the ability to play DRM content" is not a new feature. It's a defeaturing of an already existing feature: The ability to play content. It's only a feature to the content providers, but I normally don't care what new features other people like about my new computer, especially when that "feature" is being able to prevent me from doing something. But that is neither here nor there, because we aren't discussing whether such a system -should- exist, we're discussing whether or not it could exist and be friendly to free software.
NO. NO. NO. NO. NO. NO. Get it into your head. NO. The only binary that needs to be trusted is the client/player.
I don't believe you. First of all, that doesn't mesh with any other description of the system. Second, the reason for the first is that it is technically necessary.
How does the player get into memory, read disk, access hardware, or do any of the other things it needs to do to run and know it is in a trusted environment without a trusted OS? If your OS is untrusted, you're screwed.
Similarly, I'm presuming the player is going to eventually have to talk to hardware to produce audio and video. If you don't have a trusted driver, how do you do this without running the risk that the "driver" is just dumping the data to disk in DivX format?
These things are absolutely required. Hardware can be as secure as it wants, but until it knows about high-level operations of programs (ie OS level things) it is going to be vulnerable to software that breaks the security through those high-level mechanisms. The whole reason you have to have all the trusted hardware is to enable a trusted OS that can then handle loading trusted apps.
No way! If they only approve Winamp, then they lock out the whole Linux crowd.
I said only Windows player (okay, I forgot the capitalization). There is more than one Windows mp3 player, didn't you know? And "Winamp and XMMS" isn't exactly a lot of software, like you claimed. And how exactly does using OSS software lessen their burden of code review? Just because some other schmuck looked at it doesn't mean a thing. There is no way that having to go through an expensive code review process for every version of every program you want to approve is going to result in lots of software being approved.
No, no, no. Once its in memory it can't be modified. Thats all. Close the program, change it, recompile. Just remember that it has to be reapproved.
Yes, yes, yes. You say "no", then say the exact thing I said which proves my point. "Just remember that it has to be reapproved." EXACTLY. You can't recompile the program and have it do the things it used to do. If you want to make a change to XMMS and then use that program to play the content you payed for, you can't until you get your modification approved (assuming it will be).
So when I said "you can't modify it", I meant that in the sense of "it" being "the software" meaning "a program that does a specific thing". When the software can no longer do that thing, it isn't the same. I can't modify the player of my payed-for content, because once I do it ceases to be able to play that same content.
That's not free. That's faux freedom. That's like having the source to Win2k, but if you modify it you can't use it to run any Windows programs. Or a version of Office you can modify, but then can't run under Windows. Sorry, but whatever kind of freedom you call that, it is NOT the kind of freedom that the FSF means when they say free software, nor when I say free. It. Is. Not. Free.
For the last time NO. None of those things have to be compromised. Thats the beautfy of a Palladium-ified system. Trusted code can run on an untrusted operating system. The kernel, drivers, etc etc are irrelevant because the hardware is the trusted element, not the software. Thats the key.
Not in Palladium, it isn't. Maybe in some other, far-future system where hard drives have to understand ext3 and NTFS file system. Where, essentially, the reason you don't need a trusted OS is because the OS is in hardware. Palladium absolutely needs a trusted kernel.
But if you were talking about some far-future non-existant not-even-proposed system, you should have said so. I'd be happy to talk about pie-in-the-sky hypothetical systems that try to be both DRM-compliant and free software friendly, if you like. It'd be an interesting exercise to see if it is possible, since even this hypothetical system fall short.
Learn that, and re-read. And you will see that I am in fact entirely correct.
Even if everything you said regarding the system was true (and I strongly doubt this), you would still be wrong. You said it was compatible with FSF philosophy, which is untrue. The only parts that are compatible are the parts that have nothing to do with the trusted system, which is the opposite of your claim.
The only binary that needs to be trusted is the client/player.
And the operating system. And the sound/video drivers.
Not that only having to have the OS/player be trusted makes a difference -- It's not the amount of software, it's whether it can easily be free.
The middleman has vast incentive to approve as much software possible, because that directly translates into mroe revenue.
I'm not sure I see your reasoning. If WinAmp was the only windows mp3 player, how many people wouldn't be listening to mp3's? The more software = more revenue is a tenuous link when what you're selling is -content-. And code reviews are time consuming, and hence expensive. It seems that the middleman would want to minimize the amount of software that they approve for cost reasons.
Anyone can see the binary and the source.
Being able to look at the source code doesn't make it free software.
And since that portion of the system is off limits, once the hash is taken that code is permanent - it can't be modified by any portion of the system.
Exactly. You can't modify it; it isn't free.
After this code is assembled and tested, it is given to the middelman, who verifies it doesn't provide any loops. After that it is compiled against various systems and hashes are taken. This could be pretty serious job since most libraries would have to be compiled in statically - especially input/output libraries (it'd break the system if glic was linked outside the trusted portion of the system, the app would emphatically refuse to run).
And like I said before... Middlemen are going to do this for free, for XMMS, FreeAmp, XV, MPlayer, GTV, Chris Burke's Media Player... Yeah right.
Improvements would have to be re-validated by the middleman of course.
FSF philosophy is not that you should be able to modify a program to suit your needs -- so long as the changes are approved by a moneyed middleman.
This will slow down the development cycle (daily releases aren't viable in this case).
"Release early, release often" isn't exactly GNU philosophy, it has served free software well.
And I made the same observation last post -- do I really want the next kernel release held up by a middleman who could easily be in the pocket of those who are hostile to free software? Not that "you can modify the source, so long as the results are approved by a third party" is compatible with the philosophy of free software.
The binaries could be modified, as well as the source by anyone, but the program would not match the hash expected by the middleman, and encrypted content would not be decrypted and therefore played. However, that same binary would work fine with non-encrypted content.
Right. Like I said: No more compiling your own kernel. No more in-house driver development. No more actually being able to modify and recompile a program and then use it for the same things you used it for before. If you try, you lose your ability to play your paid-for content.
Furthermore, OSS systems could be fully friendly towards it, with absolute no compromise of any principles of the FSF or OSS.
I can't see how that can be. The only way this whole thing works is if the Trusted Binary you want to run cannot be read (and therefore simulated) in unencrypted form by any non-trusted application, and the Trusted System doesn't allow modified code to run as though it were the original. Being able to make modifications to programs is an important part of FSF philosophy.
The only caveat is that the software development cycle on this software will be much slower thanks to the code review needed by the middleman.
Right. And the middlemen who are deemed fit to hand out the family jewels (access to the media provider's shit) are going to code-review every program on SourceForge every time they want to release a new version for free.
I won't even go into the idea of having to pass every Linux kernel release for aproval through a middleman who could easily be in the pocket of Microsoft.
Additionally you'd have to carefully compile it on OSS systems to ensure that the key binaries are an exact match to the middlemans approved list.
How would this even work? How could I test my new Linux kernel on my machine to make sure it worked before sending it off to the Escrow Man? Or my proprietary graphics card driver?
I don't know. This doesn't seem even remotely Free Software friendly.
But the XBox has coopy protection, so by bypassing it you are breaking the law
How am I breaking the law by running Linux on an XBOX? What copy-protection scheme am I breaking? I'm not circumventing a copy-protection scheme, I'm circumventing the mechanism to prevent software not licensed by MS from running. No copyright involved.
The access control mechanism being circumvented is access to the -device-, not to copyrighted material. The DMCA only covers mechanisms controlling access to copyrighted material, not access mechanisms in general. It may be illegal to hack a DRM player to play DRM content without checking, but it isn't illegal to hack a DRM player to play non-DRM content.
If you market them as "XBox mod chips", you are admitting their primary function is to mod an XBox, and will be sued since it is illegal to market them.
Presuming you aren't using a copyrighted BIOS in your mod chip, please explain how it is illegal. Why is modifying the motherboard of a conventional PC fine, but doing the same thing to an XBOX not? There's nothing illegal about modifying something you own.
Now if the goal was to market them as "XBOX copyright evasion devices", then you might have a point.
You have the right idea, but you've made it worthless by hanging the idea on the type of government in general, and not on the character of the government at the time.
The U.S. was still technically a democracy during the fifties, but McCarthy sure managed to find a lot of people "important" enough to spy on, didn't he?
You have to understand that your observation has nothing to do with the actual organization of government (dictatorship vs democracy) and everything to do with the character of the leader. A leader with dictatorial tendencies can be as bad as a dictator, when it comes to distrust. This goes for your President, head of the FBI, or the Sheriff of your little town of good ol' boys.
People who think privacy isn't important because we live in a democracy and democracies don't spy on people are living in the same mythical world where communism makes all people equal.
Why do I need to hang so quick? Since I don't intend to blow up any children at a Tel Aviv mall any time soon
Make sure to use exactly those words when you're explaining to the shotgun-toting FBI agents who swoop in on your triangulated position why they've got the wrong guy.
Yes, if you are allowed to make mistakes in the process without dying (such as a holidek).
Great. So a UI is "intuitive" in your opinion if you only need technology from a sci-fi program set 400 years in the future in order to make the cost of attempting to use the interface without substantial training bearable.:)
But you're right, the car has a fairly intuitive interface. The reas for that is that, really, the car is a simple device. It turns, it goes, it stops, and correspondingly there are 3 knobs or levers you have to manipulate. Some cars have a 4th thing you can do (change gears), and you'll notice that is the one most people started to get confused about, and they had to get rid of. That's where the boundary lies between "difficult technology" and "simple appliance". Three things. So if your device has to do much more than go, stop, and turn left or right, it's going to be tough designing a truly intuitive interface.
And seeing how people around here drive, I'm inclined to think that three things is a bit too much.
That's why it's going to be tough to find an interface that doesn't "take a while to get used to to" for something like Blender. Which isn't to say the interface is good. I'm just saying the threshold of good should be lower than making it intuitive.
No, it isn't.
on
Blender Is GPL
·
· Score: 3, Insightful
From an engineering standpoint, it isn't bullshit at all. It's the same as processor power and power consumption. While you could in -theory- create a processor that was both fast and low power, that doesn't make it bullshit when you decide to optimize for one or the other. Interface design is engineering just the same, and you almost always have to make tradeoffs.
Well, I guess I can't really complain about the moderation of this comment. I mean, I suppose it could be considered interesting by someone else, even though I don't on the grounds that just because your pop-psychobabel is cynical that doesn't mean it isn't pop-psychobabel.
I think you may have misunderstood me. What I was saying is that you could add architectural registers without necessarily adding any physical registers.
Ah, I see now.
By the way, is it just me, or does anyone else think that Hammer's 16 register extension is shooting behind the duck? Other high-end RISCs have 32 to 64 registers. The machine I program has 64 and could make use of more in some cases. Perhaps because x86 is fundamentally a memory-operand instruction set, it can get by with fewer registers more easily? RISC-like instruction sets, with their load/store architecture, do end up needing a few more registers for values that are loaded and used immediately.
That could be. I've also heard that 16 is the number needed by database/server type apps. I've also heard that most of the time 32 reg RISC machines feel about zero register pressure, meaning they have more than enough.
But really, I'm pretty sure the decision was driven solely by wanting to minimize the impact on instruction size. The REX prefix only has room to allow for 16 registers. Whether that works out or not remains to be seen.:)
And what about conditional branches nearby? You don't know until the instruction commits what the register names will be. Imagine code which simply conditionally branches around a remap instruction. How do you handle that sanely?
The same way you handle normal register renaming in the face of branches. If you mispredict the branch, you have to flush the subsequent instructions and re-fetch. You'd have to either checkpoint or repair the RMC map, just like you do the renaming tables.
I personally think the remap idea is insane.
I agree.:)
The Pentium 4 has 128 rename registers [arstechnica.com] anyway, so it seems like adding more 'architectural registers' is more an opcode formality than anything else.
Not at all! Physical registers are no replacement for architectural. Physical registers is essentially the size of your window. They don't stop you from having to store values to memory because you don't have enough architectural registers.
But yes, the better solution is to just add architectural registers.:)
It's not that simple, or everyone would be doing this.
If no engineer ever did something that was sub-optimal, there wouldn't be anything left for other engineers to do.:)
I could just as easily say this: Personally, I don't think there should be any caller-save registers. Let the compiler's register allocator decide what registers need to be saved prior to a function body, instead of having to save a swath of them because the callee might clobber them.
Ah, but you see, those statements are not equal in magnitude.
For callee-save, the compiler knows what registers the function uses over the course of the function, and can save just those.
For caller-save, the compiler knows what registers it is using at the time of the call, and can save only those.
Registers in use at the time of the call is always going to be less than or equal to the number of registers used over the entire function. Thus caller-save wins.
Of course, as you can surmise, that's only true if you assume all functions use the same number of registers. You could conceive of a call graph where functions which use many registers frequently call functions that use few, and then callee-save wins. The question then becomes what does the typical call graph look like? What is the optimal combination of caller/callee registers for each call graph? More directly, how does each benchmark of interest perform when compiled with various combinations of caller/calle?
Since I'm willing to bet that study has not been performed, I feel okay challenging the conventional wisdom.:)
Slashdot Mirror
Somehow people seem to think that medicine comes from some magic wand that costs nothing to wave so we can have infinite research, development, production, etc. for zero or nominal cost.
;)
Nobody thinks that drugs should be free. They do think they could be made a lot cheaper than they are. And it'd be a lot more convincing when the pharamaceuticals deny this if they weren't spending twice as much on marketing as on R&D.
I mean, really, doesn't it seem a little off to be complaining of being crushed by one expense when there's another 2 1/2 times bigger?
Why are most of those drugs developed here and not in France, Mexico, or even Japan? Or even Canada? Canada is free to spend more on its health care developing its own drugs (will THEY give them to the US for free or below cost?).
Because we have the most developed pharmaceutical industry. Is that because we pump the most dollars into our medical care? Or is it because of the benefits of this country's tech industry? Or is it because of our higher education system producing the best engineers? Or is it because free trade with us means no Canada-only pharmaceuticals can get a grip there? You may as well ask why Canada doesn't produce as many cars. You haven't show cause and effect.
Meanwhile, our military does protect Canada, while it lets in terrorists and even gives them welfare so they have more time to figure out ways of killing US Citizens.
Protects Canada from whom? I'd like to point out that all these terrorists manage to make it the whole way through Canada without blowing anything up. Canada isn't their target. We're protecting nobody but ourselves.
And besides, we give our terrorists green cards even after they've commited acts of terror, so who are we to point fingers?
Personally, I think we should not be an empire, but if we are, our "friends" should recognize what it means to them.
What are you even saying here? Are you saying that Canada should be grateful for us being an empire that we shouldn't be if in fact we are?
For anyone boggling at how much Canada spends on health care (and realizing that 30% isn't the correct figure), you should know that here in the U.S. we spend roughly twice as much per-capita as the Canadians on health care (through insurance premiums, instead of taxes). The problem is that our system is so bogged down in inefficiency, that we're losing 50 cents on the dollar to middlemen. If we cut out the middlemen and maintained the same level of spending, we'd have a health system that'd put the Canadians to shame. And isn't that what it's all about? :)
Well, there ya go then. :)
:)
I only use it at work, and they don't necessarily upgrade that often.
"and now dynamic sizing/resizing in X."
Everyone is treating this like it's some super great accomplishment. Windows has allowed this since Windows 95, and the Mac since System 7.x.
Well, not exactly... What we're saying is that all the faults in useability/functionality that you may have been able to say X had are slowly and surely being whacked out. That they happen without disruption at all in compatability is a sign that there is no fundamental reason for these flaws, they are simply there because they haven't been done yet.
True, but when Windows Terminal Server came out, that takes a back seat. Try running an X11 session over a slow network link vs. a Windows terminal server session (especially over Citrix ICA) and let me know how it goes.
Depends... are we running it through ssh, telnet, or vnc? Vnc sessions are about as snappy as TS (minus the unfortunate remotely-rendered mouse of vnc). Of course Vnc suffers from the same advantage as TS, which is that it can render everything locally and compress and transmit the results.
But certainly X could use improvement in this area. That doesn't mean it won't come, or that we need to -start over-. It could be as simple as another extension.
It's not copyright extension that is the issue. While it may be true that extensions should be carefully considered as to whether they do attack the first clause, it isn't being generalized that they -all- are.
No, what is considered an attack on the first clause is retroactive extensions. Retroactive extensions are the mechanism for having perpetual copyright.
We only barely tolerate their unwashed stench becasue they have oil.
What?! When did Linux geeks get oil, and where's my share?!
It's a joke. You know, like M$. It's funny and ironic. Real, real funny.
This new, improved economic system is called "authoritarian capitalism", and is unique in that it pleases both Rand capitalists and Marx socialists, but for different reasons.
:P
The best one-sentence description of everything wrong with the modern notion of capitalism I've ever heard.
Though it scares me a little -- I shudder to think of the chance that, a hundred years from now, Ayn Rand and Karl Marx will be mentioned together.
I have yet to see anyone explain the true privacy concern of a roving wiretap.
:P
Then you haven't been paying attention. It's been done again and again.
And frankly, if you can't think of it yourself, then you're not trying very hard.
And John Ashcroft passed nothing. He doesn't want other, random people to have your info. He wants it himself. That's why he doesn't let civilians perform roving wiretaps.
This results in being able to move back and forth in time, but not being able to move away from the center of the black hole.
:)
:)
Really? I've never heard that before! I'm not a physicist, so I'm just talking about things that come up in common places.
But that's really cool. So, all you need to do is find a device that can make -itself- travel through time, and you could travel into the black hole, move yourself through time, and then use the device to move yourself out of the black hole . You've go yourself a method of time travel!
I'm of course somehow assuming it's easier to make a device that can travel through time without taking a person with it.
And that you can somehow get into the black hole alive.
etc.
No, my proposed system and Palladium are similiar in that they only "trusted" components are the nub, nexus, and fritz chip. The kernel is *not trusted*.
:)
This is not the impression of Palladium I've gotten from the documentation. I've got someone I can ask who would know for certain, so I'll do that.
Wrong. There is not a large body of digital content to play. You cant by and large get movies. You cant by and large get legal digital music. You cant by and large dowload digital books, blah blah blah. With a secure infrastructure in place you could. Your options for digital downloads of digital data would increase 10, 100, or 1000 fold. Thats a feature.
That is what the media providers keep telling us. But is the reason because they are slow to adapt new technologies, because they would rather have Palladium and are waiting for it, or because they fundamentally would not offer content without Palladium? It is not clear that, should it become the case that Palladium is soundly rejected by the populace at large, the media companies wouldn't offer digital content regardless, so as not to be left behind.
The only feature what you can claim is getting more content. But the only thing what you suggest actually does is provide content I do get with enforced restrictions. Whether that actually is a necessary and sufficient condition for the production of that content is unclear.
And it is in fact quite possible to get legal digital music. I have several gigs of good mp3's downloaded from Emusic.com. I paid for them. Clearly there are those willing to fill in the space left by major media's reluctance to enter the digital realm without a digital police officer watching our every move.
Wrong, the rapant copyright infringement we have now is what prevents you from having a lot of digital content on your desktop. Thats the stopping point.
Wrong. What prevents me from having a lot of digital content (discount my gigs of legal music for the moment) is the providers' decision not to offer it. There reason for that decision may be piracy, but they certainly do not have to make that decision. Evidence points to the possibility that piracy effects them not at all negatively, perhaps even positively. Makers of video games haven't stopped producing "digital content" because of the lack of Palladium, and they are still doing well enough for themselves. Some, like Bioware, have stopped copy protecting their games at all.
Digital content is a young market. You can no more say that the lack of digital content is the fault of piracy than I can say it's the lack of sufficient broadband capabilities to make digital content appealing to consumers. But clearly there is digital content without Palladium, and the amount of content is increasing.
So it's not inevitable at all that we can't have digital content without Palladium. The question is whether we should go to all this trouble just to make a couple of providers feel comfortable. If we say "no, we won't do that", then those providers will either give in, or be made irrelevent by providers who will. It's not like we have to get our digital content from MGM Studios or else it doesn't count, right?
No, thats not we are discussing. Thats what you are discussing. I am discussing whether a DRM system can be built without relying on security-through-obscurity.
Originally, yes. But you claimed this also was FSF friendly, and I disuputed that, and you rebutted. The topic of discussion shifted to encompass that. That happens in discussions, you know. Of course, I said we weren't discussing the "should" question, but then we discussed that, too. Eh.
Okay, you need a primer in how a system like Palladium would probably work.
System like Palladium. Stop calling it Palladium then, because that isn't what you are talking about.
The hardware chip, lets call him fritz, can be instructed to do stuff: like load code into the secure area of the system.
And where does the fritz chip get this code? Does it understand file systems, network protocols, and memory management? In other words, once it does what it would have to in order to eliminate the need for a secure OS, what need have you left for an OS at all?
So your claim that Palladium "absolutely needs a trusted trusted kernel" is false. You can pretend like you know what you are talking about. But you are wrong. It is simply untrue. Not true. Okay, not true.
But on Palladium, it is true. That is how this system is designed to work. Palladium requires a secure kernel. Your proposed system may not, but you didn't make it clear you were talking about a hypothetical system. Call it Rhodium or something, if you want to be clear.
But yes, I understand, Rhodium doesn't require a trusted kernel.
If you want to call it faux freedom, thats fine. We are reading each other completely on this, it seems to be a fundamental disagreement of what free is.
I'm going by the same definition the FSF uses. You claimed your idea was in accordance with this. It is not. That's all I'm really saying here, as far as the issue of freedom goes.
On top of that, what I described upholds the core traits of open source software - the ability to see the source. It does not uphoad the all core traits of the FSF, but the largest majority of them.
Your grasp of the core traits of the FSF is innacurate. If all they cared about was being able to see the source, then Microsoft's Shared Source would be considered free software. It isn't, because it's not. Your proposal allows little better.
it accomodates OSS code and to a much lesser degree FSF code,
Yes, good to see you backing off on that one. You've got a decent system here, with more to offer than what they currently are, at least in terms of giving us back what we already have. And no, "the ability to play DRM content" is not a new feature. It's a defeaturing of an already existing feature: The ability to play content. It's only a feature to the content providers, but I normally don't care what new features other people like about my new computer, especially when that "feature" is being able to prevent me from doing something. But that is neither here nor there, because we aren't discussing whether such a system -should- exist, we're discussing whether or not it could exist and be friendly to free software.
NO. NO. NO. NO. NO. NO.
Get it into your head. NO.
The only binary that needs to be trusted is the client/player.
I don't believe you. First of all, that doesn't mesh with any other description of the system. Second, the reason for the first is that it is technically necessary.
How does the player get into memory, read disk, access hardware, or do any of the other things it needs to do to run and know it is in a trusted environment without a trusted OS? If your OS is untrusted, you're screwed.
Similarly, I'm presuming the player is going to eventually have to talk to hardware to produce audio and video. If you don't have a trusted driver, how do you do this without running the risk that the "driver" is just dumping the data to disk in DivX format?
These things are absolutely required. Hardware can be as secure as it wants, but until it knows about high-level operations of programs (ie OS level things) it is going to be vulnerable to software that breaks the security through those high-level mechanisms. The whole reason you have to have all the trusted hardware is to enable a trusted OS that can then handle loading trusted apps.
No way! If they only approve Winamp, then they lock out the whole Linux crowd.
I said only Windows player (okay, I forgot the capitalization). There is more than one Windows mp3 player, didn't you know? And "Winamp and XMMS" isn't exactly a lot of software, like you claimed. And how exactly does using OSS software lessen their burden of code review? Just because some other schmuck looked at it doesn't mean a thing. There is no way that having to go through an expensive code review process for every version of every program you want to approve is going to result in lots of software being approved.
No, no, no. Once its in memory it can't be modified. Thats all. Close the program, change it, recompile. Just remember that it has to be reapproved.
Yes, yes, yes. You say "no", then say the exact thing I said which proves my point. "Just remember that it has to be reapproved." EXACTLY. You can't recompile the program and have it do the things it used to do. If you want to make a change to XMMS and then use that program to play the content you payed for, you can't until you get your modification approved (assuming it will be).
So when I said "you can't modify it", I meant that in the sense of "it" being "the software" meaning "a program that does a specific thing". When the software can no longer do that thing, it isn't the same. I can't modify the player of my payed-for content, because once I do it ceases to be able to play that same content.
That's not free. That's faux freedom. That's like having the source to Win2k, but if you modify it you can't use it to run any Windows programs. Or a version of Office you can modify, but then can't run under Windows. Sorry, but whatever kind of freedom you call that, it is NOT the kind of freedom that the FSF means when they say free software, nor when I say free. It. Is. Not. Free.
For the last time NO. None of those things have to be compromised. Thats the beautfy of a Palladium-ified system. Trusted code can run on an untrusted operating system. The kernel, drivers, etc etc are irrelevant because the hardware is the trusted element, not the software. Thats the key.
Not in Palladium, it isn't. Maybe in some other, far-future system where hard drives have to understand ext3 and NTFS file system. Where, essentially, the reason you don't need a trusted OS is because the OS is in hardware. Palladium absolutely needs a trusted kernel.
But if you were talking about some far-future non-existant not-even-proposed system, you should have said so. I'd be happy to talk about pie-in-the-sky hypothetical systems that try to be both DRM-compliant and free software friendly, if you like. It'd be an interesting exercise to see if it is possible, since even this hypothetical system fall short.
Learn that, and re-read. And you will see that I am in fact entirely correct.
Even if everything you said regarding the system was true (and I strongly doubt this), you would still be wrong. You said it was compatible with FSF philosophy, which is untrue. The only parts that are compatible are the parts that have nothing to do with the trusted system, which is the opposite of your claim.
It actually is very friendly.
It seems less so every time you post.
The only binary that needs to be trusted is the client/player.
And the operating system. And the sound/video drivers.
Not that only having to have the OS/player be trusted makes a difference -- It's not the amount of software, it's whether it can easily be free.
The middleman has vast incentive to approve as much software possible, because that directly translates into mroe revenue.
I'm not sure I see your reasoning. If WinAmp was the only windows mp3 player, how many people wouldn't be listening to mp3's? The more software = more revenue is a tenuous link when what you're selling is -content-. And code reviews are time consuming, and hence expensive. It seems that the middleman would want to minimize the amount of software that they approve for cost reasons.
Anyone can see the binary and the source.
Being able to look at the source code doesn't make it free software.
And since that portion of the system is off limits, once the hash is taken that code is permanent - it can't be modified by any portion of the system.
Exactly. You can't modify it; it isn't free.
After this code is assembled and tested, it is given to the middelman, who verifies it doesn't provide any loops. After that it is compiled against various systems and hashes are taken. This could be pretty serious job since most libraries would have to be compiled in statically - especially input/output libraries (it'd break the system if glic was linked outside the trusted portion of the system, the app would emphatically refuse to run).
And like I said before... Middlemen are going to do this for free, for XMMS, FreeAmp, XV, MPlayer, GTV, Chris Burke's Media Player... Yeah right.
Improvements would have to be re-validated by the middleman of course.
FSF philosophy is not that you should be able to modify a program to suit your needs -- so long as the changes are approved by a moneyed middleman.
This will slow down the development cycle (daily releases aren't viable in this case).
"Release early, release often" isn't exactly GNU philosophy, it has served free software well.
And I made the same observation last post -- do I really want the next kernel release held up by a middleman who could easily be in the pocket of those who are hostile to free software? Not that "you can modify the source, so long as the results are approved by a third party" is compatible with the philosophy of free software.
The binaries could be modified, as well as the source by anyone, but the program would not match the hash expected by the middleman, and encrypted content would not be decrypted and therefore played. However, that same binary would work fine with non-encrypted content.
Right. Like I said: No more compiling your own kernel. No more in-house driver development. No more actually being able to modify and recompile a program and then use it for the same things you used it for before. If you try, you lose your ability to play your paid-for content.
Sounds pretty hostile to me.
Furthermore, OSS systems could be fully friendly towards it, with absolute no compromise of any principles of the FSF or OSS.
I can't see how that can be. The only way this whole thing works is if the Trusted Binary you want to run cannot be read (and therefore simulated) in unencrypted form by any non-trusted application, and the Trusted System doesn't allow modified code to run as though it were the original. Being able to make modifications to programs is an important part of FSF philosophy.
The only caveat is that the software development cycle on this software will be much slower thanks to the code review needed by the middleman.
Right. And the middlemen who are deemed fit to hand out the family jewels (access to the media provider's shit) are going to code-review every program on SourceForge every time they want to release a new version for free.
I won't even go into the idea of having to pass every Linux kernel release for aproval through a middleman who could easily be in the pocket of Microsoft.
Additionally you'd have to carefully compile it on OSS systems to ensure that the key binaries are an exact match to the middlemans approved list.
How would this even work? How could I test my new Linux kernel on my machine to make sure it worked before sending it off to the Escrow Man? Or my proprietary graphics card driver?
I don't know. This doesn't seem even remotely Free Software friendly.
But the XBox has coopy protection, so by bypassing it you are breaking the law
How am I breaking the law by running Linux on an XBOX? What copy-protection scheme am I breaking? I'm not circumventing a copy-protection scheme, I'm circumventing the mechanism to prevent software not licensed by MS from running. No copyright involved.
The access control mechanism being circumvented is access to the -device-, not to copyrighted material. The DMCA only covers mechanisms controlling access to copyrighted material, not access mechanisms in general. It may be illegal to hack a DRM player to play DRM content without checking, but it isn't illegal to hack a DRM player to play non-DRM content.
If you market them as "XBox mod chips", you are admitting their primary function is to mod an XBox, and will be sued since it is illegal to market them.
Presuming you aren't using a copyrighted BIOS in your mod chip, please explain how it is illegal. Why is modifying the motherboard of a conventional PC fine, but doing the same thing to an XBOX not? There's nothing illegal about modifying something you own.
Now if the goal was to market them as "XBOX copyright evasion devices", then you might have a point.
You have the right idea, but you've made it worthless by hanging the idea on the type of government in general, and not on the character of the government at the time.
The U.S. was still technically a democracy during the fifties, but McCarthy sure managed to find a lot of people "important" enough to spy on, didn't he?
You have to understand that your observation has nothing to do with the actual organization of government (dictatorship vs democracy) and everything to do with the character of the leader. A leader with dictatorial tendencies can be as bad as a dictator, when it comes to distrust. This goes for your President, head of the FBI, or the Sheriff of your little town of good ol' boys.
People who think privacy isn't important because we live in a democracy and democracies don't spy on people are living in the same mythical world where communism makes all people equal.
Why do I need to hang so quick? Since I don't intend to blow up any children at a Tel Aviv mall any time soon
Make sure to use exactly those words when you're explaining to the shotgun-toting FBI agents who swoop in on your triangulated position why they've got the wrong guy.
Yes, if you are allowed to make mistakes in the process without dying (such as a holidek).
:)
Great. So a UI is "intuitive" in your opinion if you only need technology from a sci-fi program set 400 years in the future in order to make the cost of attempting to use the interface without substantial training bearable.
But you're right, the car has a fairly intuitive interface. The reas for that is that, really, the car is a simple device. It turns, it goes, it stops, and correspondingly there are 3 knobs or levers you have to manipulate. Some cars have a 4th thing you can do (change gears), and you'll notice that is the one most people started to get confused about, and they had to get rid of. That's where the boundary lies between "difficult technology" and "simple appliance". Three things. So if your device has to do much more than go, stop, and turn left or right, it's going to be tough designing a truly intuitive interface.
And seeing how people around here drive, I'm inclined to think that three things is a bit too much.
That's why it's going to be tough to find an interface that doesn't "take a while to get used to to" for something like Blender. Which isn't to say the interface is good. I'm just saying the threshold of good should be lower than making it intuitive.
From an engineering standpoint, it isn't bullshit at all. It's the same as processor power and power consumption. While you could in -theory- create a processor that was both fast and low power, that doesn't make it bullshit when you decide to optimize for one or the other. Interface design is engineering just the same, and you almost always have to make tradeoffs.
Well, I guess I can't really complain about the moderation of this comment. I mean, I suppose it could be considered interesting by someone else, even though I don't on the grounds that just because your pop-psychobabel is cynical that doesn't mean it isn't pop-psychobabel.
I think you may have misunderstood me. What I was saying is that you could add architectural registers without necessarily adding any physical registers.
:)
Ah, I see now.
By the way, is it just me, or does anyone else think that Hammer's 16 register extension is shooting behind the duck? Other high-end RISCs have 32 to 64 registers. The machine I program has 64 and could make use of more in some cases. Perhaps because x86 is fundamentally a memory-operand instruction set, it can get by with fewer registers more easily? RISC-like instruction sets, with their load/store architecture, do end up needing a few more registers for values that are loaded and used immediately.
That could be. I've also heard that 16 is the number needed by database/server type apps. I've also heard that most of the time 32 reg RISC machines feel about zero register pressure, meaning they have more than enough.
But really, I'm pretty sure the decision was driven solely by wanting to minimize the impact on instruction size. The REX prefix only has room to allow for 16 registers. Whether that works out or not remains to be seen.
And what about conditional branches nearby? You don't know until the instruction commits what the register names will be. Imagine code which simply conditionally branches around a remap instruction. How do you handle that sanely?
:)
:)
The same way you handle normal register renaming in the face of branches. If you mispredict the branch, you have to flush the subsequent instructions and re-fetch. You'd have to either checkpoint or repair the RMC map, just like you do the renaming tables.
I personally think the remap idea is insane.
I agree.
The Pentium 4 has 128 rename registers [arstechnica.com] anyway, so it seems like adding more 'architectural registers' is more an opcode formality than anything else.
Not at all! Physical registers are no replacement for architectural. Physical registers is essentially the size of your window. They don't stop you from having to store values to memory because you don't have enough architectural registers.
But yes, the better solution is to just add architectural registers.
It's not that simple, or everyone would be doing this.
:)
:)
If no engineer ever did something that was sub-optimal, there wouldn't be anything left for other engineers to do.
I could just as easily say this:
Personally, I don't think there should be any caller-save registers. Let the compiler's register allocator decide what registers need to be saved prior to a function body, instead of having to save a swath of them because the callee might clobber them.
Ah, but you see, those statements are not equal in magnitude.
For callee-save, the compiler knows what registers the function uses over the course of the function, and can save just those.
For caller-save, the compiler knows what registers it is using at the time of the call, and can save only those.
Registers in use at the time of the call is always going to be less than or equal to the number of registers used over the entire function. Thus caller-save wins.
Of course, as you can surmise, that's only true if you assume all functions use the same number of registers. You could conceive of a call graph where functions which use many registers frequently call functions that use few, and then callee-save wins. The question then becomes what does the typical call graph look like? What is the optimal combination of caller/callee registers for each call graph? More directly, how does each benchmark of interest perform when compiled with various combinations of caller/calle?
Since I'm willing to bet that study has not been performed, I feel okay challenging the conventional wisdom.