Because while there is a little overlap, "the developers" of Linux and "the developers" of Fedora/Mandrake/etc and "the developers" of Mono are different people.
W3C compliant, I think. We are trying to modularize the code more, though, to provide a basis for other (possibly non-SVG-based) tools (implemented by us or someone else). It might eventually mean an internal or external fork, but that's okay. People gotta do what they need.
The other thing is that once we've reached a decent level of SVG-compliance we should be in a pretty good shape to get involved with the development of the SVG spec and help nudge it in appropriate directions.
I'm one of the founding developers. We might joke about being an Illustrator killer occasionally, but really that's not what we're about. That wouldn't be a healthy focus, and the _best_ we could hope for in that case would be becoming a (marginally) better Illustrator clone.
That wouldn't be so great, IMO. Illustrator does a lot of things, but it doesn't always do them well, and the UI is painful at times.
Realistically, we are going to do some things well which Illustrator does poorly, and we will do some things poorly which Illustrator does well.
We just wanna make a good and useful tool and be the best we can be dammit. All this "foo-killer" stuff is silliness. ^^;
Bear in mind that the main Inkscape developers are also heavy users. We have to eat our own dogfood, so that usually keeps us from doing anything too stupid (for very long).
That aside, if you don't like the way the project is run you can always fork or find a different one. That's how we started Inkscape after all, and I'm not going to be hypocritical about it. ^_-
Color models are going to be tricky... SVG is currently limited to only sRGB by CSS2/3. We're trying to find clean ways to extend SVG/CSS without breaking backwards compatability (and of course we're tracking future W3C proposals along these lines).
Basically, the plan is groups = layers. I implemented a first cut at that a long time ago (set inkscape:groupmode="layer" on a group [hopefully I'm remembering the attribtue name here..]), but nobody's gotten around to doing UI for it yet.
I expect it'll get done fairly soon since even I'm beginning to feel the pain of not having it implemented all the way yet. ^_-
So users are always more or less traceable by IP, which open HTTP proxies tend to prevent. This helps e.g. when trying to enforce IP bans. Of course as the other poster noted, it creates problems for users who really need to be anonymous.
Historically "ultimate breakdowns" tend to be very, very messy, painful and ultimately counterproductive. The American Revolution was highly unusual; look to the French Revolution for a more typical example of how things can turn out.
Of course, if the government is successful enough in the application of fear then things will stabilize as you suggest, but I think that'd still be a pretty miserable situation to live in.
I like your technical analysis; I just don't share your optimism about the human factors involved.
IMO, working to effect cultural changes is really paramount, lest we end up in a bloody mess, or stuck in an oppressive "local minimum". Along those lines, I think e.g. Creative Commons is a positive effort.
Not that I'm going to fault technological efforts either -- technology is really a cultural activity, isn't it?
This is problably farther than they plan to go in the initial phase, but if I were designing the protocol and receiver hardware, I'd include timestamps in the protocol to prevent such "replay attacks".
Actually, come to think of it... existing broadcast proposals for HDTV aren't simple boolean flags, but "expiry times" (albeit relative, not absolute). So there you are.
To really do it right, I imagine they'll eventually try mandating receiving hardware that sets its own internal clock via NIST's WWVB or similar (and shuts off if the signal is blocked). That'd work pretty well, since spoofing or interfering with that signal will already get you in deep trouble...
Implementation of a "broadcast flag" is listed as Goal One. Goal two is... wait for it... "plugging the analog hole".
Of course there are easy technical ways to bypass any such schemes if you can get your hands on uncrippled A/D hardware. Your student or journalist is welcome to take advantage of them if they are willing to risk going to prison.
Slashdot Mirror
*palm to forehead*
oh yeah.. ^^;
Isn't the boehm collector generational?
Because while there is a little overlap, "the developers" of Linux and "the developers" of Fedora/Mandrake/etc and "the developers" of Mono are different people.
W3C compliant, I think. We are trying to modularize the code more, though, to provide a basis for other (possibly non-SVG-based) tools (implemented by us or someone else). It might eventually mean an internal or external fork, but that's okay. People gotta do what they need.
The other thing is that once we've reached a decent level of SVG-compliance we should be in a pretty good shape to get involved with the development of the SVG spec and help nudge it in appropriate directions.
So we'll see how it works out.
Just the light you personally observe, or would any light do?
Thank you.
Agreed.
I'm one of the founding developers. We might joke about being an Illustrator killer occasionally, but really that's not what we're about. That wouldn't be a healthy focus, and the _best_ we could hope for in that case would be becoming a (marginally) better Illustrator clone.
That wouldn't be so great, IMO. Illustrator does a lot of things, but it doesn't always do them well, and the UI is painful at times.
Realistically, we are going to do some things well which Illustrator does poorly, and we will do some things poorly which Illustrator does well.
We just wanna make a good and useful tool and be the best we can be dammit. All this "foo-killer" stuff is silliness. ^^;
Bear in mind that the main Inkscape developers are also heavy users. We have to eat our own dogfood, so that usually keeps us from doing anything too stupid (for very long).
That aside, if you don't like the way the project is run you can always fork or find a different one. That's how we started Inkscape after all, and I'm not going to be hypocritical about it. ^_-
Color models are going to be tricky ... SVG is currently limited to only sRGB by CSS2/3. We're trying to find clean ways to extend SVG/CSS without breaking backwards compatability (and of course we're tracking future W3C proposals along these lines).
Basically, the plan is groups = layers. I implemented a first cut at that a long time ago (set inkscape:groupmode="layer" on a group [hopefully I'm remembering the attribtue name here..]), but nobody's gotten around to doing UI for it yet.
I expect it'll get done fairly soon since even I'm beginning to feel the pain of not having it implemented all the way yet. ^_-
We are a fork of the Sodipodi project; this is highlighted further on in the article.
We (the Inkscape developers, anyway) currently use Scribus for PDF and EPS output when we need it.
Scribus is kind of a sister project, and we've been working closely with them to get perfect import of Inkscape SVGs.
That's not to say that Inkscape shouldn't have PDF etc support in the future, but it's already not too painful if you have Scribus handy.
So users are always more or less traceable by IP, which open HTTP proxies tend to prevent. This helps e.g. when trying to enforce IP bans. Of course as the other poster noted, it creates problems for users who really need to be anonymous.
Yes, Slashdot does a check for open HTTP proxies.
Historically "ultimate breakdowns" tend to be very, very messy, painful and ultimately counterproductive. The American Revolution was highly unusual; look to the French Revolution for a more typical example of how things can turn out.
Of course, if the government is successful enough in the application of fear then things will stabilize as you suggest, but I think that'd still be a pretty miserable situation to live in.
I like your technical analysis; I just don't share your optimism about the human factors involved.
IMO, working to effect cultural changes is really paramount, lest we end up in a bloody mess, or stuck in an oppressive "local minimum". Along those lines, I think e.g. Creative Commons is a positive effort.
Not that I'm going to fault technological efforts either -- technology is really a cultural activity, isn't it?
That's really brilliant.
Make sure you publish somewhere prominent so the prior art is documented and this doesn't get buried by patents.
I'm sure they tried. IIRC they spent more money on miscellaneous occult research than on their atomic bomb efforts.
No, an unenforceable law is a law which can be selectively enforced to political ends.
I take your point, though.
Wanna bet? We came very, very close to losing the VCR that way, and things aren't as clear-cut this time around.
Does anyone think this card sounds too much like the start of a something like the "Listener's License" in Tales from the Afternow?
(especially if combined with measures like those I consider here...)
What a wonderful illustration of the Prisoners' Dilemma.
Actually, you're still thinking of this as a technical, not a legal problem. So was my last answer.
All that's necessary is to make it illegal to receive or record these signals with unapproved devices.
At that point, in combination with the other measures I outlined, your "fair use" becomes de-facto evidence of your criminal act.
Welcome to jail. Do not pass Go. Do not collect $200.
This is problably farther than they plan to go in the initial phase, but if I were designing the protocol and receiver hardware, I'd include timestamps in the protocol to prevent such "replay attacks".
... existing broadcast proposals for HDTV aren't simple boolean flags, but "expiry times" (albeit relative, not absolute). So there you are.
Actually, come to think of it
To really do it right, I imagine they'll eventually try mandating receiving hardware that sets its own internal clock via NIST's WWVB or similar (and shuts off if the signal is blocked). That'd work pretty well, since spoofing or interfering with that signal will already get you in deep trouble...
Our job is to make sure they never get that far.
I shouldn't say something like that without backing it up.
... wait for it ... "plugging the analog hole".
Here: Content Protection Status Report
Implementation of a "broadcast flag" is listed as Goal One. Goal two is
Of course there are easy technical ways to bypass any such schemes if you can get your hands on uncrippled A/D hardware. Your student or journalist is welcome to take advantage of them if they are willing to risk going to prison.
What if the necessary equipment were illegal? That has been publically discussed...