Why on earth would you serve a perfectly standard Inkscape SVG that you had then gzipped as image/svg+xml? Isn't that misleading?
No it's not. Read the spec , and you'll find that this is completely correct.
The MIME type for SVG is "image/svg+xml" (always). And the extension for gzip compressed SVG files is ".svgz". And gzip is the only compression type which the spec allows for.
So? It's a prerelease version. Not the same as the final release. My snapshot from a few days ago tells me: gcc version 4.1.0 20050417 (experimental)
Doesn't mean it's the final 4.1 release, does it?
Re:Figured this had to happen
on
GCC 4.0.0 Released
·
· Score: 5, Informative
When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.
Well, you're wrong because GCC doesn't follow Apple's schedule, or anyone else's for that matter. Even a cursory glance at the GCC mailing list will tell you that.
The reason Apple can promise this is that they're not actually shipping GCC 4. They're shipping their own fork of the GCC 4 code. It's probably about 99% the same code, but don't make the mistake of thinking they're shipping exactly what the FSF is distributing.
If SCO was so anti-linux, why would they make a move to incorporate linux into its own product. That step right there discounts any claims they might have regarding linux code source.
No it doesn't. They weren't incorporating Linux code. They were making a compatibility layer so you could run Linux apps; BSD has one too.
But the main thing is: SCO was not at all anti-linux until Darl McBride entered the game as new CEO after Ransom Love. SCO was a Linux distributor, forchrissakes! (And that, however, may invalidate any claims they had on Linux code, since by distributing, they are bound to follow the GPL)
However in reality they don't have any claims on Linux. Despite what they've been repeatedly telling the press, they haven't claimed in court that Linux infringes on their Unix copyrights. What they claimed in court was that IBM couldn't contribute to Linux since they had a Unix license. (Although the contract seems to indicate otherwise).
They made some other claims, too, but in reality the SCO-IBM case has very little to do with Linux at all. IBM's counterclaims regarding SCO's public statements and GPL violations are actually the more directly Linux-related things in this whole mess.
Ok then. A quick and dirty human translation follows.
Norwegian-to-English translators are rather difficult to find.
I don't think so.:) Of course, I know norwegian.
[first page] Not all our worklogs are boring boxes and water-cooling. Now, the constructor of the TUX-cabinet hits us with the Futurama-character Bender in full scale.
Bizardo's project is one of the few truely original parts of our worklog-division and is something which definitely can be called "one of a kind".
Those of us at Overklokking.no have chosen to highlight Bizardo's project due to its originality and execution. The project should be an insipration to anyone wanting something other than a standard box.
The following article is writtne by Bizardo himself, where he choses to present his Project Bender. Those of us at Overklokking.no are grateful for him sharing it with us, and hope to see more of his work later.
[second page]
Foreword After finishing my TUX project, I just had to do something new.. I thought about what to do for months and had several good ideas, but finally I fell for Bender:D I've always been a big Futurama fan and I was 100% certain I'd be able to do this, dispite how much time and money I'd spend. I would never have been able to finish this project if I hadn't had help from my friends: Einhar Flå - welding, Geir Gravem - math genius who calculated angles and proportions. So a big thanks to these guys.:)
Planning
How big was it going to be? And how to fit it all together? This needed to be thought through and I figured out that I could first build a full-figure paper figure first, and then make all the mistakes I wanted without wasting time and sheet-metal.
This was used in the project:
* 1 Slim slotload DVD ROM/CD-burner from Carputer.no
* 1 VIA EPIA-M 10000 Mini-ITX motherboard
* WLAN-kort with antenna
* 2 10 watt light-bulbs (12volt)
* 1 120 GB harddisk + 4 external 250 GB disks on firewire
* Metal ducts (for feet and hands)
* 3 Metal kitchen-bowls from Coop (for the top of the head, and legs)
* 4-5 paper sheets
* 3 0,7 mm pieces of steel sheet-metal
* 1 Digital voice recorder from Produkt 24
After playing with different 3d programs I managed to print this 3D-model. I used it as a blueprint where I filled in the measurements for size, and so on.
And so the work with the paper-figure started, calculating angles, finding the correct proportions, etc.
There, we have a paper-figure, very crooked and stuff. With this paper figure all we have to do is spread out the sheets of paper on the sheet-metal and use them as a template:). Now when all templates and parts we need are finished, we can start building.:D
[third page]
Building Bender
The eyes used are 10 watt halogen bulbs running on 12 volts, wired to the PSU:). Since these are only 10 watts and wired serially, they don't get very warm and don't use much power.
Then it was time to start with Bender's body. Started with taking out the paper-model and putting it on the sheet-metal for marking:
Then the cutting began.
The sheet-metal was cut, rolled until completely round and then welded together.
At last Bender was taking shape, but just the same a lot of work remained.
And then there was Bender's head:
A lot of people thought the head would be a problem considering that the top of the head is round. But it wasn't. Coop [Norwegian co-op supermarket] has metal kitchen bowls. These bowls had just the right diameter and everything, talk about luck:D
Now when the head is finished it has to be mounted on the body and holes have to be cut for the doors
2)Really weird phyics like this doesn't start happening until things get really cold. Think tenths or hundredths of a degree above absolute zero. Of course, since energy and temperature are related concepts, at absolute zero, there is no energy, and nothing moves.
That's not true. According to the laws of physics, a system cannot have an exactly energy (such as zero), it would violate Heisenberg's uncertainty principle. There are random fluctuations in energy, even at 0 K. It's called zero-point energy.
Less temperature = less energy (e). the speed of light (c) decreases at the same rate as the square root of e. At asbolute zero, e=0 c=0 m=infinity. Time has no meaning to light. Time only slows down/speeds up when your velocity changes with respect to the speed of light. If you were in the supercooled state, time would in fact slow down.
This is complete nonsense. c is constant regardless of temperature/energy. Time does not slow down if you are cold. Your timeframe is slower when you are cold, as seen relative a warm state. Knowing the formula for time dilation and understanding it are two different thigns.
At ultracold tempearture, Einstein predicted that really funky things would happen. Matter as we think of it tends to break down. It's called the Bose-Einstein condensate.
That's not really true either. Most matter out there are not bosons and cannot form Bose-Einstein condensates. You can't make a BEC out of most molecules.
Great, now the gene splicers have the equivalent of a hex editor, but still have no clue what they are editing.
They've had that for a long time. This is just a new one. Don't exaggerate the importance.
It's like hacking binary code out of one program and inserting into another program and somehow getting it to work.
A bit. But not quite as random as that. In this case, they know what the gene in question codes for a certain protein which acts as a receptor on T-cells. They know what the gene looks like in a healthy person. They know what it looks like in a person with the disease. They know that without this protein, the T-cell will die. They know that without T-cells the immune system won't work.
They don't know every last detail of the mechanism. But in this case; do they need to?
They know that replacing these faulty cells will cure the disease. This can be done through a bone-marrow transplant from a healthy person. (Donors for which are very hard to come by)
If any am being overcautious or am ill-informed please feel free to correct me. I try to live by the motto, "Just because we can do something, doesn't mean we should." This applies to System Administration as much as it does to gene-hacking.
Yes you're being overcautious, I think. You're missing the point that this disease already has been cured through other methods. You're missing that they know what the effects of changing this are. You're missing the point that these patients have a terrible quality of life and a very short life-expectancy. The alternative is literally letting them die.
You're missing the fact that they already are very cautious. They're not talking about using gene therapy to cure the common cold here. Gene therapy has so far only been used in cases like this, for very deadly diseases which we understand relatively well.
So this treatment actually alters the genetic code of a human?
Yes it changes the genetic code. But it's not a treatment yet. It's a method which could be developed in a treatment. There's quite some difference between changing the DNA of a cell in a test-tube and doing it in someone's body. (In medical terms: in vitro versus in vivo)
So any genetic disease would not get passed down to future generations? How is something like this administered? Our DNA is found in every cell of our body.
Well, exactly. And you don't really want to try to change the DNA of every cell in the body, because you don't have to, you only need to change the DNA in some of the relevant cells. Mucking about with other cells (such as your sperm cells) would increase the risks.
If you read the article, what they're planning to do is take blood from the body, treat it, and reinject it.
(Although I think that sounds a bit strange; The disease is caused by faulty T-cells, which are in the blood. Shouldn't they be fixing the bone marrow cells, which create the T-cells? That's what these other treatments do. But this isn't my field.)
I don't know about "intentions" - licenses explicitly limit one's *actions*.
What part of "the FSF's intentions" didn't you understand? I understood it to imply "the FSF's intentions with respect to the new GPL license" or "What the FSF wants with their new license" what does that have to do with the definition of the word license?
It is you who misrepresents "distribution" in the same self-serving way as those who are working on breaking the GPL in a revision. "Distribution" is significant when it happens between separate groups of people. If I run a PostgreSQL cluster in my one-man shop, I'm not distributing the SW in any way relevant to rights or the license (since there's sensibly no per-CPU terms).
You're not even trying to understand. This is not about the definition of 'distribution'.
This is about the fact that you can distribute (under whatever definition you think is relevant) the full functionality of a piece of software. This is, and should be considered equivalent to distributing the software itself. My other post in this thread gave a concrete example of that.
Currently, the GPL does not cover this. It should.
If the FSF has problems with the move of software distribution from physical media to networks, which the current GPL doesn't cover, they can patch that small technical problem.
And that is exactly what they are doing.
If they have a problem that they're not exploiting their power in the community to get more concessions from consumers of GPL software than before, that's their problem, not mine.
I have no idea what you mean by that. They don't want more concessions from anybody. They want the same things as they wanted before, only that it shouldn't matter if you're giving someone a CD-rom with the program on it, or giving someone a web-interface to the program.
Since so many people, including the submitter, seem to completely misunderstand what the FSF means here, perhaps an example will demonstrate:
Case 1: I download the Gimp and make a bunch of additions and changes to it. I then want to sell my modified version on a CD. That's just fine, but as the Gimp is under the GPL I have to include the sources.
Case 2: I download the Gimp and make a bunch of additions and changes to it. I then want to sell my modified version. I distribute a small proprietary program which opens an X connection to my server and runs my version of Gimp over the network. Under the GPL as it stands, I am not 'distributing' my modified version of the Gimp, and I don't need to share the source with anyone.
The difference in user functionality between these two cases is zero (well, assuming a fast server and network). But I have managed to successfuly circumvent the GPL.
The current principle is that if someone gets an executable from you, they also can get the source code, just as you got the source code from which you made your executable. Just using the source code, or customizing it for your own use, doesn't require distributing the source. The new principle would be requiring anyone who customized the source to release all customizations.
No, that would not be the new principle. You and the submitter have completely misunderstood the FSF's intentions here.
The intention here is that if you allow the program to be used in a distributed environment, you are doing something which most would consider equivalent to distributing the program itself.
And in accordance with the first principle you mentioned, you should then be required to give access to the source.
There is not a very big difference between giving someone a copy of a program so they can run it on their machine, and giving them full access to run it remotely on your machine.
this guy had an itch (he wanted a Gimp UI more similar to PS), he scratched it and released his modifications so other with the same itch could benefit. There's absolutely NOTHING wrong with that from the point of view of 'free software development', the whole 'due process' angle is in some way like trying to put some limits on that freedom!
Noone said it was wrong. But it's stupid. It's stupid not to collaborate if you can. And in this case, the impression I get is that he did have the opportunity to collaborate directly with the Gimp folks, and achieve mutual benefit. And he didn't do that. I can fully understand if the Gimp devs are a bit sour; not because what he did was wrong, but because it's frustrating to see someone do good work and then shoot themselves in the foot by making it incompatible for no reason. And the impression BigSven gives is that it could've been avoided if he'd bothered to contact people with a better understanding of the Gimp internals beforehand.
It's as if the Gimp devs said 'yeah, we released things under a license that allows you to do this, BUT, you really should not exercise your rights and instead partecipate in xyz committee that might or might not decide that your itch is worth scratching'.
No, what the Gimp devs are saying is that you can exersize your rights and do whatever you want, but we'd be much happier if you cooperated with us, so that we could achive something benefitial to everybody.
A development model based on 'scratching an itch' is fine for an emergent OS, with Linux coming more and more in the mainstream users expect to be listened to, catered to and most of all respected, and not told to 'code it or shut up'.
Then I suggest those users go buy a supported distribution like Red Hat and send their requests to their developers. But nobody can tell anyone else what they can and can't do in their own time, and as long as the work is being done by unpaid developers working in their own time, that is just not realistic.
Personally, when coding free software, I do try to listen to users and respect their requests. But I do not tolerate the idea that I'm under any kind of obligation to do so. If the users are going to come to expect that, then they'll have to be prepared to be disappointed as you were.
In this case the non-free software world is better
Yes, it is. But not quite for the reason you stated. The non-free software development is supply-and-demand, where the 'demand' part is that of the paying users. In free software development the 'demand' part is that of the developers themselves.
I don't think this is a major problem. It's not like the opinions of users and developers are radically different. Or very different at all. Personally I think the Gimp UI is absolutely horrible. (although somewhat better in 2.0), and this guy obviously thought so too.
I'm not the guy, so I don't really know his motivations, but he might have felt that 'do first, ask for permission later' was best in this case to create buzz about this issue.
Um, yeah. But it seems he didn't do that either. Seems the guy hasn't made any effort to work with the Gimp people, even when they contacted him.
That is unpolite, whatever way you look at it.
Obviously when faced with LOTS of users cheering this modification the Gimp developers will be a lot more open to the idea than if a lone developer asked for this feature through the 'proper channels'.
No, no, no. The Gimp developers know a lot of people want a PS-similar interface. It's been talked about for years. But it seems the people actually hacking on Gimp were happy with the interface as it was. That doesn't mean they wouldn't want to give it a "PS theme" if someone was willing to do wone. It just means they weren't willing to do it themselves.
Again, you don't seem to understand that there's a big difference between whinging "I want a Photoshop-like UI!!" and actually approaching them with "Hey, I've got a Photoshop-like UI here, do you want it?".
A user asking for a feature is asking is nothing more and nothing less than someone asking a complete stranger to spend hours of his time doing him a favour. You simply can't expect that unless the guy he's asking wants it himself.
Now actually contributing is offering someone a favour. And that is a completely different matter.
It would be nice if the Gimp devs listened to some experienced PS folks (not me, I'm no expert) who could point them in the right direction in terms of features users REALLY want vs features that the devs want.
That is simply not going to happen. Free software development doesn't work like that. It's software developed by people 'scratching an itch' for something they want. Now for some people, perhaps that itch is 'helping others'. But I assure you they are in the minority. You never have any guarantee a feature will be present unless you're either willing to code it yourself or pay someone to do so.
they chose a license for Gimp that allows this kind of modification, the guy was definitely within his rights to go ahead with it whether or not Sven (or others) would've preferred him to 'work with them and not fork things'.
Noone implied he didn't have the legal right to do so. He's not violating the law, just unwritten rules of etiquette; It's polite to try to cooperate before forking.
The real issue here, which the poster mentioned, isn't that he forked Gimp, it's that it seems he may have changed parts which didn't have to be changed in order to achive what he did. That's doing a disservice both to both parties, since it'll make it more difficult to merge in his changes into the Gimp, and newer changes to the Gimp into GimpShop.
If he had 'followed due process' he'd just have been ignored because 'Gimp is not Photoshop'.
What exactly do you base this on? The Gimp developer who posted seemed quite open to the idea. There's a big difference between developers not considering requests from users and developers not considering an implementation of said request.
FYI, the various.NET/Mono languages are all JIT'd, zero interpreting. Java is much the same now, it was just originally designed to be an interpreted language.
Wrong, and wrong.
First, off JIT doesn't mean "zero interpreting", no JIT VM compiles all code. It's simply not efficient to do so. And all that code is interpreted.
Second, Sun's first VM for Java was an interpreter, but Java was not at all designed to be an interpreted language. In fact, it was designed with allowing JIT VMs in mind. (And Sun's JIT VM was publicly released in '96, only two years after Java itself)
Also,.NET/Mono have ahead-of-time (AOT) compilation, meaning you can compile your dll libraries or exe applications to native code at install time.
Yes, but please note that this is performing the compilation the JIT does ahead-of-time, which again isn't all of code. So it's not the same thing as conventional compiling to native code. (Although the difference isn't big performance-wise)
Right, which is why they're developing it. In ten years, a human infant is no longer an infant. Of course, it remains to be seen whether nanotech can sustain a similar level of growth.
Right, and like a human infant, you can't be certain if they're going to grow up to be a farmer or a jazz pianist.
Out of all the possible applications of nanotech, it's not possible to predict which ones will succeed and which will fail.
Will we be using nanotech in 20 years? I have no doubt. What we will be using it for? Not sure.
Calling it a "robot scientist" goes a bit too far.
Correlation is not causation and science isn't about finding lots of empirical observations and correlations, it's about understanding why you have these correlations.
You can build a robot which turns on and off light-switches, which will automatically make the observation that it will lead to a light going on 99% of the time. But it still takes real intelligence to understand why that happens.
Now in this case, the robot does 'create' hypothesis itself. But only within the limits of its programming. In other words, it will automate the 'discovery' of things where you already have a very good idea of how it works.
Now that is useful, but it's hardly going to change science as we know it. Obviously, it will never be able to discover something completely new and original (which is the most interesting kind of discovery).
Also, it is only useful for areas where the research is being conducted in a very systematic manner, which isn't the case for most of science. In most science, it's not just a question of finding out stuff. That's usually the easier part, actually. The big problem is finding out how to find out.
Reverse engineering is understanding the behavior without looking at the innards, strictly from observing its behavior under different conditions.
No, it's not. Reverse engineering, as it's most commonly used, and as it's always been used, means nothing more and nothing less than "Finding out how the thing works."
Any and every method used to do that is a form of reverse-engineering. Decompilation is such a method. It is not the only method.
The word you are actually looking for is clean-room. "Clean-room" reverse-engineering is that which is done without looking at the other's code. Or, in a less strict sense it means reimplementing something without the person writing the new implementation having seen the code of the old one. This is usually done by having one person reverse-engineer the software (by whatever method) and write a full specification, from which the implementer can work. That way, you have documentation showing that any similarities between the implementations are purely coincidental.
Yes, please, don't be a retard. Heaven knows there are enough of them already.
Perhaps you should stop flaming people over words until you actually know what they mean yourself?
Most licences prohibit "reverse engineering" too - it's just not enforcable since the local laws explicitly allow reverse engineering. Of course IANAL so I can't tell you if the lagal "reverse engineering for interoperability purposes" also include disassembly. I would think it did.
Spot on. The Norwegian law, on this, paragraph 39i, is a translation of European law 91/250/EEC, article 6.
Both allow reverse-engineering for interoperability purposes, both specifically mention decompilation.
The Norwegian law has also added the following line to the end of the paragraph: Bestemmelsene i denne paragraf kan ikke fravikes ved avtale., which means The regulations of this paragraph cannot be waived through agreement. That is, any EULA or contract clause forbidding reverse engineering for interoperability is void.
Although, if some Slashdotters read their EULAs more carefully, they'd probably have noticed that most of them already take this into account and forbid "reverse engineering except as allowed under law" or something to that extent.
Nintendo vs Accolade man. That's the case that determined that copying into memory is making a copy under copyright law. It has been upheld in every case since.
So? I'm not disputing that either. But you have gone from saying it's a derivative work, to saying that it's an 'unauthorized modification' to saying that it's banned by the EULA. You're not making any sense. If 'any court in the land' would slam down on 'unauthorized modification' what does Nintendo vs Accolade have to do with anything?
Firstly, Does the GTA EULA disallow modification of the copy you have in memory? Disallowing modification of a program you have in memory would inable you to even *run* the goddamn thing. Where in the EULA is this prohibited?
Secondly, even if such a paragraph exists, it's highly doubtful if it's enforcable. EULAs as a whole are doubtful, and Vault vs. Quaid showed exactly that an EULA which prohibited reverse-engineering and modification was not enforceable.
Thirdly, modifying a program you have legally purchased, without redistributing the modified version will almost undoubtadly fall under fair-use provisions. Nintendo vs. Accolade isn't relevant to that.
Proprietary software like GTA 3 is supplied under a license which prohibits making derivative works. That means you are not permitted to make a derivative work by combining the software with other software in memory.
Yes, they have. So? That encroaches on fair-use provisions. Point out a ruling enforcing that part of the license.
Now I hear you, you're going to say that even if the user is violating their license with the supplier of GTA3 the creators of MTA are not breaking any laws, right? Well no, because they are encouraging others to break copyright law. That's contributory copyright infringement.
That is an even more specious argument. Point out some case-law to support that. There is certainly cases saying quite the opposite. See Vault vs. Quaid for instance. (Although that case specifically is about a program which removed a copy-protection device, now illegal under the DMCA, I cannot see why the court would rule differently for a similar program with a different purpose.)
pah-lease. When you run the game, with modifications, the work you are using is a derivative work of the original. There isn't a court in the land that would not strike such unauthorised modifications down.
And what land would that be? Presumably one inside your head. Seriously, study the damn subject before making moronic declarations like that.
Yes, modifying copyrighted material creates a derivative work. So what? Creating a derivative work is not illegal. Anywhere.
Copyright law is about reproduction, publication, public performances, and distribution. You are not allowed to do that with a derivative work without permission. Creating on is a completely different matter. As long as you do not publish, distribute and so on the derivative work you are not violating any law, anywhere. (and the program which modifies the original GTA is *not* a derivative work in itself, since it does not contain any parts of the copyrighted original.)
What you are saying is that it is illegal for someone to go and buy a book and go home and rewrite one of the chapters in it. Do you really believe this yourself?
What you are not allowed to do is to take that rewritten book and distribute it.
Slashdot Mirror
Why on earth would you serve a perfectly standard Inkscape SVG that you had then gzipped as image/svg+xml? Isn't that misleading?
No it's not. Read the spec , and you'll find that this is completely correct.
The MIME type for SVG is "image/svg+xml" (always). And the extension for gzip compressed SVG files is ".svgz". And gzip is the only compression type which the spec allows for.
No, shame on you for implying that this bug had anything to do with that accident.
So? It's a prerelease version. Not the same as the final release. My snapshot from a few days ago tells me:
gcc version 4.1.0 20050417 (experimental)
Doesn't mean it's the final 4.1 release, does it?
When they announced the release of Apple 10.4 "Tiger" I noticed this page: At that point I kinda figured gcc 4.0.0 had to be out by April 29th since Apple claimed they were using it for OS X.
Well, you're wrong because GCC doesn't follow Apple's schedule, or anyone else's for that matter. Even a cursory glance at the GCC mailing list will tell you that.
The reason Apple can promise this is that they're not actually shipping GCC 4. They're shipping their own fork of the GCC 4 code. It's probably about 99% the same code, but don't make the mistake of thinking they're shipping exactly what the FSF is distributing.
If SCO was so anti-linux, why would they make a move to incorporate linux into its own product. That step right there discounts any claims they might have regarding linux code source.
No it doesn't. They weren't incorporating Linux code. They were making a compatibility layer so you could run Linux apps; BSD has one too.
But the main thing is: SCO was not at all anti-linux until Darl McBride entered the game as new CEO after Ransom Love. SCO was a Linux distributor, forchrissakes!
(And that, however, may invalidate any claims they had on Linux code, since by distributing, they are bound to follow the GPL)
However in reality they don't have any claims on Linux. Despite what they've been repeatedly telling the press, they haven't claimed in court that Linux infringes on their Unix copyrights. What they claimed in court was that IBM couldn't contribute to Linux since they had a Unix license. (Although the contract seems to indicate otherwise).
They made some other claims, too, but in reality the SCO-IBM case has very little to do with Linux at all. IBM's counterclaims regarding SCO's public statements and GPL violations are actually the more directly Linux-related things in this whole mess.
OK...I challenge you to find a better one.
:) Of course, I know norwegian.
:D I've always been a big Futurama fan and I was 100% certain I'd be able to do this, dispite how much time and money I'd spend. I would never have been able to finish this project if I hadn't had help from my friends: Einhar Flå - welding, Geir Gravem - math genius who calculated angles and proportions. So a big thanks to these guys. :)
:). Now when all templates and parts we need are finished, we can start building. :D
:). Since these are only 10 watts and wired serially, they don't get very warm and don't use much power.
:D
Ok then. A quick and dirty human translation follows.
Norwegian-to-English translators are rather difficult to find.
I don't think so.
[first page]
Not all our worklogs are boring boxes and water-cooling. Now, the constructor of the TUX-cabinet hits us with the Futurama-character Bender in full scale.
Bizardo's project is one of the few truely original parts of our worklog-division and is something which definitely can be called "one of a kind".
Those of us at Overklokking.no have chosen to highlight Bizardo's project due to its originality and execution. The project should be an insipration to anyone wanting something other than a standard box.
The following article is writtne by Bizardo himself, where he choses to present his Project Bender. Those of us at Overklokking.no are grateful for him sharing it with us, and hope to see more of his work later.
[second page]
Foreword
After finishing my TUX project, I just had to do something new.. I thought about what to do for months and had several good ideas, but finally I fell for Bender
Planning
How big was it going to be? And how to fit it all together? This needed to be thought through and I figured out that I could first build a full-figure paper figure first, and then make all the mistakes I wanted without wasting time and sheet-metal.
This was used in the project:
* 1 Slim slotload DVD ROM/CD-burner from Carputer.no
* 1 VIA EPIA-M 10000 Mini-ITX motherboard
* WLAN-kort with antenna
* 2 10 watt light-bulbs (12volt)
* 1 120 GB harddisk + 4 external 250 GB disks on firewire
* Metal ducts (for feet and hands)
* 3 Metal kitchen-bowls from Coop (for the top of the head, and legs)
* 4-5 paper sheets
* 3 0,7 mm pieces of steel sheet-metal
* 1 Digital voice recorder from Produkt 24
After playing with different 3d programs I managed to print this 3D-model. I used it as a blueprint where I filled in the measurements for size, and so on.
And so the work with the paper-figure started, calculating angles, finding the correct proportions, etc.
There, we have a paper-figure, very crooked and stuff. With this paper figure all we have to do is spread out the sheets of paper on the sheet-metal and use them as a template
[third page]
Building Bender
The eyes used are 10 watt halogen bulbs running on 12 volts, wired to the PSU
Then it was time to start with Bender's body. Started with taking out the paper-model and putting it on the sheet-metal for marking:
Then the cutting began.
The sheet-metal was cut, rolled until completely round and then welded together.
At last Bender was taking shape, but just the same a lot of work remained.
And then there was Bender's head:
A lot of people thought the head would be a problem considering that the top of the head is round. But it wasn't. Coop [Norwegian co-op supermarket] has metal kitchen bowls. These bowls had just the right diameter and everything, talk about luck
Now when the head is finished it has to be mounted on the body and holes have to be cut for the doors
How big is that 'junk file'?
2)Really weird phyics like this doesn't start happening until things get really cold. Think tenths or hundredths of a degree above absolute zero. Of course, since energy and temperature are related concepts, at absolute zero, there is no energy, and nothing moves.
That's not true. According to the laws of physics, a system cannot have an exactly energy (such as zero), it would violate Heisenberg's uncertainty principle. There are random fluctuations in energy, even at 0 K. It's called zero-point energy.
Less temperature = less energy (e). the speed of light (c) decreases at the same rate as the square root of e. At asbolute zero, e=0 c=0 m=infinity. Time has no meaning to light. Time only slows down/speeds up when your velocity changes with respect to the speed of light. If you were in the supercooled state, time would in fact slow down.
This is complete nonsense. c is constant regardless of temperature/energy. Time does not slow down if you are cold. Your timeframe is slower when you are cold, as seen relative a warm state. Knowing the formula for time dilation and understanding it are two different thigns.
At ultracold tempearture, Einstein predicted that really funky things would happen. Matter as we think of it tends to break down. It's called the Bose-Einstein condensate.
That's not really true either. Most matter out there are not bosons and cannot form Bose-Einstein condensates. You can't make a BEC out of most molecules.
Great, now the gene splicers have the equivalent of a hex editor, but still have no clue what they are editing.
They've had that for a long time. This is just a new one. Don't exaggerate the importance.
It's like hacking binary code out of one program and inserting into another program and somehow getting it to work.
A bit. But not quite as random as that. In this case, they know what the gene in question codes for a certain protein which acts as a receptor on T-cells. They know what the gene looks like in a healthy person. They know what it looks like in a person with the disease. They know that without this protein, the T-cell will die. They know that without T-cells the immune system won't work.
They don't know every last detail of the mechanism. But in this case; do they need to?
They know that replacing these faulty cells will cure the disease. This can be done through a bone-marrow transplant from a healthy person. (Donors for which are very hard to come by)
If any am being overcautious or am ill-informed please feel free to correct me. I try to live by the motto, "Just because we can do something, doesn't mean we should." This applies to System Administration as much as it does to gene-hacking.
Yes you're being overcautious, I think. You're missing the point that this disease already has been cured through other methods. You're missing that they know what the effects of changing this are. You're missing the point that these patients have a terrible quality of life and a very short life-expectancy. The alternative is literally letting them die.
You're missing the fact that they already are very cautious. They're not talking about using gene therapy to cure the common cold here. Gene therapy has so far only been used in cases like this, for very deadly diseases which we understand relatively well.
So this treatment actually alters the genetic code of a human?
Yes it changes the genetic code. But it's not a treatment yet. It's a method which could be developed in a treatment. There's quite some difference between changing the DNA of a cell in a test-tube and doing it in someone's body. (In medical terms: in vitro versus in vivo)
So any genetic disease would not get passed down to future generations? How is something like this administered? Our DNA is found in every cell of our body.
Well, exactly. And you don't really want to try to change the DNA of every cell in the body, because you don't have to, you only need to change the DNA in some of the relevant cells. Mucking about with other cells (such as your sperm cells) would increase the risks.
If you read the article, what they're planning to do is take blood from the body, treat it, and reinject it.
(Although I think that sounds a bit strange; The disease is caused by faulty T-cells, which are in the blood. Shouldn't they be fixing the bone marrow cells, which create the T-cells? That's what these other treatments do. But this isn't my field.)
I don't know about "intentions" - licenses explicitly limit one's *actions*.
What part of "the FSF's intentions" didn't you understand? I understood it to imply "the FSF's intentions with respect to the new GPL license" or "What the FSF wants with their new license" what does that have to do with the definition of the word license?
It is you who misrepresents "distribution" in the same self-serving way as those who are working on breaking the GPL in a revision. "Distribution" is significant when it happens between separate groups of people. If I run a PostgreSQL cluster in my one-man shop, I'm not distributing the SW in any way relevant to rights or the license (since there's sensibly no per-CPU terms).
You're not even trying to understand. This is not about the definition of 'distribution'.
This is about the fact that you can distribute (under whatever definition you think is relevant) the full functionality of a piece of software. This is, and should be considered equivalent to distributing the software itself. My other post in this thread gave a concrete example of that.
Currently, the GPL does not cover this. It should.
If the FSF has problems with the move of software distribution from physical media to networks, which the current GPL doesn't cover, they can patch that small technical problem.
And that is exactly what they are doing.
If they have a problem that they're not exploiting their power in the community to get more concessions from consumers of GPL software than before, that's their problem, not mine.
I have no idea what you mean by that. They don't want more concessions from anybody. They want the same things as they wanted before, only that it shouldn't matter if you're giving someone a CD-rom with the program on it, or giving someone a web-interface to the program.
Since so many people, including the submitter, seem to completely misunderstand what the FSF means here, perhaps an example will demonstrate:
Case 1: I download the Gimp and make a bunch of additions and changes to it. I then want to sell my modified version on a CD. That's just fine, but as the Gimp is under the GPL I have to include the sources.
Case 2: I download the Gimp and make a bunch of additions and changes to it. I then want to sell my modified version. I distribute a small proprietary program which opens an X connection to my server and runs my version of Gimp over the network. Under the GPL as it stands, I am not 'distributing' my modified version of the Gimp, and I don't need to share the source with anyone.
The difference in user functionality between these two cases is zero (well, assuming a fast server and network). But I have managed to successfuly circumvent the GPL.
This is what the FSF wants to stop.
The current principle is that if someone gets an executable from you, they also can get the source code, just as you got the source code from which you made your executable. Just using the source code, or customizing it for your own use, doesn't require distributing the source. The new principle would be requiring anyone who customized the source to release all customizations.
No, that would not be the new principle. You and the submitter have completely misunderstood the FSF's intentions here.
The intention here is that if you allow the program to be used in a distributed environment, you are doing something which most would consider equivalent to distributing the program itself.
And in accordance with the first principle you mentioned, you should then be required to give access to the source.
There is not a very big difference between giving someone a copy of a program so they can run it on their machine, and giving them full access to run it remotely on your machine.
this guy had an itch (he wanted a Gimp UI more similar to PS), he scratched it and released his modifications so other with the same itch could benefit. There's absolutely NOTHING wrong with that from the point of view of 'free software development', the whole 'due process' angle is in some way like trying to put some limits on that freedom!
Noone said it was wrong. But it's stupid. It's stupid not to collaborate if you can. And in this case, the impression I get is that he did have the opportunity to collaborate directly with the Gimp folks, and achieve mutual benefit. And he didn't do that. I can fully understand if the Gimp devs are a bit sour; not because what he did was wrong, but because it's frustrating to see someone do good work and then shoot themselves in the foot by making it incompatible for no reason. And the impression BigSven gives is that it could've been avoided if he'd bothered to contact people with a better understanding of the Gimp internals beforehand.
It's as if the Gimp devs said 'yeah, we released things under a license that allows you to do this, BUT, you really should not exercise your rights and instead partecipate in xyz committee that might or might not decide that your itch is worth scratching'.
No, what the Gimp devs are saying is that you can exersize your rights and do whatever you want, but we'd be much happier if you cooperated with us, so that we could achive something benefitial to everybody.
A development model based on 'scratching an itch' is fine for an emergent OS, with Linux coming more and more in the mainstream users expect to be listened to, catered to and most of all respected, and not told to 'code it or shut up'.
Then I suggest those users go buy a supported distribution like Red Hat and send their requests to their developers. But nobody can tell anyone else what they can and can't do in their own time, and as long as the work is being done by unpaid developers working in their own time, that is just not realistic.
Personally, when coding free software, I do try to listen to users and respect their requests. But I do not tolerate the idea that I'm under any kind of obligation to do so. If the users are going to come to expect that, then they'll have to be prepared to be disappointed as you were.
In this case the non-free software world is better
Yes, it is. But not quite for the reason you stated. The non-free software development is supply-and-demand, where the 'demand' part is that of the paying users. In free software development the 'demand' part is that of the developers themselves.
I don't think this is a major problem. It's not like the opinions of users and developers are radically different. Or very different at all. Personally I think the Gimp UI is absolutely horrible. (although somewhat better in 2.0), and this guy obviously thought so too.
I'm not the guy, so I don't really know his motivations, but he might have felt that 'do first, ask for permission later' was best in this case to create buzz about this issue.
Um, yeah. But it seems he didn't do that either. Seems the guy hasn't made any effort to work with the Gimp people, even when they contacted him.
That is unpolite, whatever way you look at it.
Obviously when faced with LOTS of users cheering this modification the Gimp developers will be a lot more open to the idea than if a lone developer asked for this feature through the 'proper channels'.
No, no, no. The Gimp developers know a lot of people want a PS-similar interface. It's been talked about for years. But it seems the people actually hacking on Gimp were happy with the interface as it was. That doesn't mean they wouldn't want to give it a "PS theme" if someone was willing to do wone. It just means they weren't willing to do it themselves.
Again, you don't seem to understand that there's a big difference between whinging "I want a Photoshop-like UI!!" and actually approaching them with "Hey, I've got a Photoshop-like UI here, do you want it?".
A user asking for a feature is asking is nothing more and nothing less than someone asking a complete stranger to spend hours of his time doing him a favour. You simply can't expect that unless the guy he's asking wants it himself.
Now actually contributing is offering someone a favour. And that is a completely different matter.
It would be nice if the Gimp devs listened to some experienced PS folks (not me, I'm no expert) who could point them in the right direction in terms of features users REALLY want vs features that the devs want.
That is simply not going to happen. Free software development doesn't work like that. It's software developed by people 'scratching an itch' for something they want. Now for some people, perhaps that itch is 'helping others'. But I assure you they are in the minority. You never have any guarantee a feature will be present unless you're either willing to code it yourself or pay someone to do so.
they chose a license for Gimp that allows this kind of modification, the guy was definitely within his rights to go ahead with it whether or not Sven (or others) would've preferred him to 'work with them and not fork things'.
Noone implied he didn't have the legal right to do so. He's not violating the law, just unwritten rules of etiquette; It's polite to try to cooperate before forking.
The real issue here, which the poster mentioned, isn't that he forked Gimp, it's that it seems he may have changed parts which didn't have to be changed in order to achive what he did. That's doing a disservice both to both parties, since it'll make it more difficult to merge in his changes into the Gimp, and newer changes to the Gimp into GimpShop.
If he had 'followed due process' he'd just have been ignored because 'Gimp is not Photoshop'.
What exactly do you base this on? The Gimp developer who posted seemed quite open to the idea. There's a big difference between developers not considering requests from users and developers not considering an implementation of said request.
FYI, the various .NET/Mono languages are all JIT'd, zero interpreting. Java is much the same now, it was just originally designed to be an interpreted language.
.NET/Mono have ahead-of-time (AOT) compilation, meaning you can compile your dll libraries or exe applications to native code at install time.
Wrong, and wrong.
First, off JIT doesn't mean "zero interpreting", no JIT VM compiles all code. It's simply not efficient to do so. And all that code is interpreted.
Second, Sun's first VM for Java was an interpreter, but Java was not at all designed to be an interpreted language. In fact, it was designed with allowing JIT VMs in mind. (And Sun's JIT VM was publicly released in '96, only two years after Java itself)
Also,
Yes, but please note that this is performing the compilation the JIT does ahead-of-time, which again isn't all of code. So it's not the same thing as conventional compiling to native code. (Although the difference isn't big performance-wise)
Right, which is why they're developing it. In ten years, a human infant is no longer an infant. Of course, it remains to be seen whether nanotech can sustain a similar level of growth.
Right, and like a human infant, you can't be certain if they're going to grow up to be a farmer or a jazz pianist.
Out of all the possible applications of nanotech, it's not possible to predict which ones will succeed and which will fail.
Will we be using nanotech in 20 years? I have no doubt. What we will be using it for? Not sure.
Bah, too easy to get the Theatre Multiball.
I'd go with Scared Stiff!
Calling it a "robot scientist" goes a bit too far.
Correlation is not causation and science isn't about finding lots of empirical observations and correlations, it's about understanding why you have these correlations.
You can build a robot which turns on and off light-switches, which will automatically make the observation that it will lead to a light going on 99% of the time. But it still takes real intelligence to understand why that happens.
Now in this case, the robot does 'create' hypothesis itself. But only within the limits of its programming. In other words, it will automate the 'discovery' of things where you already have a very good idea of how it works.
Now that is useful, but it's hardly going to change science as we know it. Obviously, it will never be able to discover something completely new and original (which is the most interesting kind of discovery).
Also, it is only useful for areas where the research is being conducted in a very systematic manner, which isn't the case for most of science. In most science, it's not just a question of finding out stuff. That's usually the easier part, actually. The big problem is finding out how to find out.
Reverse engineering is understanding the behavior without looking at the innards, strictly from observing its behavior under different conditions.
No, it's not. Reverse engineering, as it's most commonly used, and as it's always been used, means nothing more and nothing less than "Finding out how the thing works."
Any and every method used to do that is a form of reverse-engineering. Decompilation is such a method. It is not the only method.
The word you are actually looking for is clean-room. "Clean-room" reverse-engineering is that which is done without looking at the other's code. Or, in a less strict sense it means reimplementing something without the person writing the new implementation having seen the code of the old one. This is usually done by having one person reverse-engineer the software (by whatever method) and write a full specification, from which the implementer can work. That way, you have documentation showing that any similarities between the implementations are purely coincidental.
Yes, please, don't be a retard. Heaven knows there are enough of them already.
Perhaps you should stop flaming people over words until you actually know what they mean yourself?
Most licences prohibit "reverse engineering" too - it's just not enforcable since the local laws explicitly allow reverse engineering. Of course IANAL so I can't tell you if the lagal "reverse engineering for interoperability purposes" also include disassembly. I would think it did.
Spot on. The Norwegian law, on this, paragraph 39i, is a translation of European law 91/250/EEC, article 6.
Both allow reverse-engineering for interoperability purposes, both specifically mention decompilation.
The Norwegian law has also added the following line to the end of the paragraph: Bestemmelsene i denne paragraf kan ikke fravikes ved avtale., which means The regulations of this paragraph cannot be waived through agreement.
That is, any EULA or contract clause forbidding reverse engineering for interoperability is void.
Although, if some Slashdotters read their EULAs more carefully, they'd probably have noticed that most of them already take this into account and forbid "reverse engineering except as allowed under law" or something to that extent.
Nintendo vs Accolade man. That's the case that determined that copying into memory is making a copy under copyright law. It has been upheld in every case since.
So? I'm not disputing that either. But you have gone from saying it's a derivative work, to saying that it's an 'unauthorized modification' to saying that it's banned by the EULA. You're not making any sense. If 'any court in the land' would slam down on 'unauthorized modification' what does Nintendo vs Accolade have to do with anything?
Firstly, Does the GTA EULA disallow modification of the copy you have in memory? Disallowing modification of a program you have in memory would inable you to even *run* the goddamn thing. Where in the EULA is this prohibited?
Secondly, even if such a paragraph exists, it's highly doubtful if it's enforcable. EULAs as a whole are doubtful, and Vault vs. Quaid showed exactly that an EULA which prohibited reverse-engineering and modification was not enforceable.
Thirdly, modifying a program you have legally purchased, without redistributing the modified version will almost undoubtadly fall under fair-use provisions. Nintendo vs. Accolade isn't relevant to that.
Proprietary software like GTA 3 is supplied under a license which prohibits making derivative works. That means you are not permitted to make a derivative work by combining the software with other software in memory.
Yes, they have. So? That encroaches on fair-use provisions. Point out a ruling enforcing that part of the license.
Now I hear you, you're going to say that even if the user is violating their license with the supplier of GTA3 the creators of MTA are not breaking any laws, right? Well no, because they are encouraging others to break copyright law. That's contributory copyright infringement.
That is an even more specious argument. Point out some case-law to support that. There is certainly cases saying quite the opposite. See Vault vs. Quaid for instance.
(Although that case specifically is about a program which removed a copy-protection device, now illegal under the DMCA, I cannot see why the court would rule differently for a similar program with a different purpose.)
pah-lease. When you run the game, with modifications, the work you are using is a derivative work of the original. There isn't a court in the land that would not strike such unauthorised modifications down.
And what land would that be? Presumably one inside your head. Seriously, study the damn subject before making moronic declarations like that.
Yes, modifying copyrighted material creates a derivative work. So what? Creating a derivative work is not illegal. Anywhere.
Copyright law is about reproduction, publication, public performances, and distribution. You are not allowed to do that with a derivative work without permission. Creating on is a completely different matter. As long as you do not publish, distribute and so on the derivative work you are not violating any law, anywhere.
(and the program which modifies the original GTA is *not* a derivative work in itself, since it does not contain any parts of the copyrighted original.)
What you are saying is that it is illegal for someone to go and buy a book and go home and rewrite one of the chapters in it. Do you really believe this yourself?
What you are not allowed to do is to take that rewritten book and distribute it.