http://realbasic.com/community/designawards/2005/
"Made with REALbasic" != "Absolute crap, guaranteed"
A design award won by REALbasic applications is not indicative of the quality of software developed in REALbasic if the award is for REALbasic apps only.
Company A then sues B for copyright infringement for using their drivers.
But B wouldn't have pretend that they wrote the driver, or even publish it. As long as A has managed to get their driver on the Windows Install CD, all B has to do is to release a product that will work with that driver. The customer already has it, and telling the customer to "use driver for product Z by company A" is not illegal.
Actually, Linux has desktop origins. Linus wrote it because he wanted to have a decent Unix-like kernel (and, together with GNU, system) for the 386. Consider also that Linus defined the goal for 1.0 as "X11 works".
Writing code of that quality that looks like it does what it's supposed to do, while actually doing something subtly different, sounds like a very difficult challenge to me.
Programmers do that every day. It's called a "bug". Now, doing something subtly different and controlling what the subtly different thing actually is, that is a challenge.
Because they don't use a moving print head, the width of the paper is of no consequence. By placing two A6-heads side by side, they could get DIN A4 at 150ppm (A4 = 210x297 mm which is 8.27x11.7 in for you non-metric types)
Drying the stuff is another matter and they don't go into detail, but I'm ready to assume that they're not stupid.
Do you think they may start to converge again with this development?
Personally, I don't think that it will come to a point where the codebases converge completely, but I'm hoping for a better patch exchange between the two projects. WebKit and KHTML have their strength and weaknesses in different area and could benefit from increased collaboration.
Would Apple have done this had they not complained?
As has been said here for about a thousand times, the KHTML devels didn't complain, they just asked their users to give them the credit they deserve instead of giving it to Apple, because Apple had effectively forked KHTML and development was happening in parallel. This got misreported as a flame against Apple.
Under the "agreement", Apple could use KHTML as the renderer in their Safari browser, _if_ they returned all changes to the source code.
No, all the LGPL says is that Apple has to publish its changes, which they did in a giant tarball. They did not get involved in hacking KHTML and are not about to do that now, but then, they weren't required to do so. The "agreement", as you call it, was fullfilled. Still, some open source users (not the KHTML devels) thought that this was not enough and raised a stink. Apple got concerned about the bad PR and asked what they could do to simplify the KHTML developers' life, and releasing their changes in a CVS with history was one of the items on the list.
Now, we will continue to reap the benefits of both freelance and corporate coding.
That still remains to be seen. While the CVS makes the merger easier, it's still not a trivial task. KHTML and WebKit have diverged quite a bit since the fork.
They did release all their changes as one giant tarball, which, while complying with the license, is not a good basis for merging back changes. They did not get actively involved in hacking KHTML, instead they did a classic fork. This is not bashing Apple, just trying to bust some myths.
OSS people got upset as they wanted more.
KHTML developers never complained about Apple's way of doing things. They were annoyed about users saying "This is fixed in Safari, why isn't it fixed in KHTML? They are the same thing!", so they pointed out that no, it wasn't, and merging with Apple is no easy task, because (a) the codebases have diverged so much and (b) the format in which Apple publishes its changes is, while legally sufficient, not an good one for merging changes back. Somehow, that was interpreted as complaining about Apple, while all they were really doing was trying to bust the myth that KHTML and Webkit are still the same thing.
The problem here is the amount of data that needs to be transferred: You need all the textures, models, objects, everything from a scene before you can even start rendering. That can be quite a significant amount of bytes. And the resulting rendered frames are, while not large, still huge in comparison to SETI@Home. To sum it up, the CPU-time/data-size ratio is not as favourable.
Consider that even in "professional" render farms of a few hundred nodes on a LAN, the delivery of scene data and return of rendered frames is a major bottleneck and needs to be planned carefully if your hundreds of nodes should not be sitting there waiting for the file server.
Apparently, there is no requirement for German ISPs to keep a record of IP addresses
There is not only no requirement to keep the data, the ISPs (and everybody else) are prohibited to keep personal data (which includes anything that might identify an individual) unless immediately required for conducting their business or explicitely allowed by the customer. In other words, people are suing because the providers are not complying to German Datenschutz (data protection) laws.
Hyper Transport has nothing to do with Hyper Threading. Hyper Threading means processor support for several (usually two) execution threads at once. Hyper Transport is a bus technology to interconnect pocessors, RAM, motherboard chips, PCI bus and the like.
AMD's Hyper Transport is similar to Intel's Hyper Threading, but in my books, superior.
That's like saying that the computers from Apple Computers are similar but superior to the computers from Apple Records. Notice how Apple Records makes no computers? Just because they start with the same word does not mean two things are the same.
Are you being intentionally dense? Currently, there's loads of stuff that you need (word processor,...) that is not OS-agnostic. That might change. Not with today's browser, but in the future. Already, Google's UIs are classes better that standard web apps.
Because, as we all know, radio transmissions can't be intercepted
Well yeah, but that'ld be hard to do. First of all, GSM has a certain amount of encryption and obfuscation - not enough to stop a determined hacker, but it's much harder to snoop on a GSM connection than on an analog connection.
The real problem in intercepting the message would be to be in the right spot to hear it. The SMS only goes over the air in the cell the bank customer's phone is currently sitting in. Your hacker would have to be there, too - that guy would have to be really determined to break your bank account, specifically, not just any old one.
Re:I don't get it
on
Gates on Google
·
· Score: 2, Interesting
I don't buy this, a browser on a machine with no OS
No, not without an OS, but the browser and the OS would stop mattering - as long as it can do Google, it can do anything you want. MS would have a hard time charging as much as they do for Windows if all it is used for is launching a browser.
Perversly, a lot of people have less trouble installing a plugin than configuring their web browsers correctly. Plus, a plugin is better for marketing.
Secondly, it seems that this will leverage (*grin*) Google's existing caching infrastructure. I don't know how well that maps to the standard proxy server model - it might not.
The Fine Article states that while Google's results are comparable to Netcraft's server survey results (that is, their share of Apache and IIS represents the respective market share), MSN seems to favor IIS. So no, Google does not favor Apache.
I have no idea how you set out to become the de facto standard other than getting everyone to use it.
Right. TFA about this:
If you want your design to become a standard, two words mean more than anything else: good documentation. You need good, clear, documentation that covers everything people need to know to implement your standard, and you need it to be easily available. Don't think of this as a trade secret. Think of it as the published interface to encourage other people to use your product. The documentation should be as complete as you can manage. Be sure to solicit feedback. If people ask questions, make sure the documentation answers those questions.
Slashdot Mirror
http://realbasic.com/community/designawards/2005/
"Made with REALbasic" != "Absolute crap, guaranteed"
A design award won by REALbasic applications is not indicative of the quality of software developed in REALbasic if the award is for REALbasic apps only.
Company A then sues B for copyright infringement for using their drivers.
But B wouldn't have pretend that they wrote the driver, or even publish it. As long as A has managed to get their driver on the Windows Install CD, all B has to do is to release a product that will work with that driver. The customer already has it, and telling the customer to "use driver for product Z by company A" is not illegal.Its server origins betray it [Linux]
Actually, Linux has desktop origins. Linus wrote it because he wanted to have a decent Unix-like kernel (and, together with GNU, system) for the 386. Consider also that Linus defined the goal for 1.0 as "X11 works".
Writing code of that quality that looks like it does what it's supposed to do, while actually doing something subtly different, sounds like a very difficult challenge to me.
Programmers do that every day. It's called a "bug". Now, doing something subtly different and controlling what the subtly different thing actually is, that is a challenge.
They specifically say the code has to be readable and harmless-looking.
(no/text)
But how many decimeters per troy ounce does it get?
28532
The width of the paper may be of no consequence, but the length is.
You're right. I'm going to hide in the corner now.Because they don't use a moving print head, the width of the paper is of no consequence. By placing two A6-heads side by side, they could get DIN A4 at 150ppm (A4 = 210x297 mm which is 8.27x11.7 in for you non-metric types)
Drying the stuff is another matter and they don't go into detail, but I'm ready to assume that they're not stupid.
Do you think they may start to converge again with this development?
Personally, I don't think that it will come to a point where the codebases converge completely, but I'm hoping for a better patch exchange between the two projects. WebKit and KHTML have their strength and weaknesses in different area and could benefit from increased collaboration.Would Apple have done this had they not complained?
As has been said here for about a thousand times, the KHTML devels didn't complain, they just asked their users to give them the credit they deserve instead of giving it to Apple, because Apple had effectively forked KHTML and development was happening in parallel. This got misreported as a flame against Apple.Under the "agreement", Apple could use KHTML as the renderer in their Safari browser, _if_ they returned all changes to the source code.
No, all the LGPL says is that Apple has to publish its changes, which they did in a giant tarball. They did not get involved in hacking KHTML and are not about to do that now, but then, they weren't required to do so. The "agreement", as you call it, was fullfilled. Still, some open source users (not the KHTML devels) thought that this was not enough and raised a stink. Apple got concerned about the bad PR and asked what they could do to simplify the KHTML developers' life, and releasing their changes in a CVS with history was one of the items on the list.
Now, we will continue to reap the benefits of both freelance and corporate coding.
That still remains to be seen. While the CVS makes the merger easier, it's still not a trivial task. KHTML and WebKit have diverged quite a bit since the fork.They had contributed back
They did release all their changes as one giant tarball, which, while complying with the license, is not a good basis for merging back changes. They did not get actively involved in hacking KHTML, instead they did a classic fork. This is not bashing Apple, just trying to bust some myths.OSS people got upset as they wanted more.
KHTML developers never complained about Apple's way of doing things. They were annoyed about users saying "This is fixed in Safari, why isn't it fixed in KHTML? They are the same thing!", so they pointed out that no, it wasn't, and merging with Apple is no easy task, because (a) the codebases have diverged so much and (b) the format in which Apple publishes its changes is, while legally sufficient, not an good one for merging changes back. Somehow, that was interpreted as complaining about Apple, while all they were really doing was trying to bust the myth that KHTML and Webkit are still the same thing.The problem here is the amount of data that needs to be transferred: You need all the textures, models, objects, everything from a scene before you can even start rendering. That can be quite a significant amount of bytes. And the resulting rendered frames are, while not large, still huge in comparison to SETI@Home. To sum it up, the CPU-time/data-size ratio is not as favourable. Consider that even in "professional" render farms of a few hundred nodes on a LAN, the delivery of scene data and return of rendered frames is a major bottleneck and needs to be planned carefully if your hundreds of nodes should not be sitting there waiting for the file server.
Apparently, there is no requirement for German ISPs to keep a record of IP addresses
There is not only no requirement to keep the data, the ISPs (and everybody else) are prohibited to keep personal data (which includes anything that might identify an individual) unless immediately required for conducting their business or explicitely allowed by the customer. In other words, people are suing because the providers are not complying to German Datenschutz (data protection) laws.
Alice Uber Deutchland
Alice above Germany? In a plane, or what?Hyper Transport has nothing to do with Hyper Threading. Hyper Threading means processor support for several (usually two) execution threads at once. Hyper Transport is a bus technology to interconnect pocessors, RAM, motherboard chips, PCI bus and the like.
AMD's Hyper Transport is similar to Intel's Hyper Threading, but in my books, superior.
That's like saying that the computers from Apple Computers are similar but superior to the computers from Apple Records. Notice how Apple Records makes no computers? Just because they start with the same word does not mean two things are the same.
Are you being intentionally dense? Currently, there's loads of stuff that you need (word processor,...) that is not OS-agnostic. That might change. Not with today's browser, but in the future. Already, Google's UIs are classes better that standard web apps.
Think about "Mozilla, the platform".
Because, as we all know, radio transmissions can't be intercepted
Well yeah, but that'ld be hard to do. First of all, GSM has a certain amount of encryption and obfuscation - not enough to stop a determined hacker, but it's much harder to snoop on a GSM connection than on an analog connection.
The real problem in intercepting the message would be to be in the right spot to hear it. The SMS only goes over the air in the cell the bank customer's phone is currently sitting in. Your hacker would have to be there, too - that guy would have to be really determined to break your bank account, specifically, not just any old one.
I don't buy this, a browser on a machine with no OS
No, not without an OS, but the browser and the OS would stop mattering - as long as it can do Google, it can do anything you want. MS would have a hard time charging as much as they do for Windows if all it is used for is launching a browser.Perversly, a lot of people have less trouble installing a plugin than configuring their web browsers correctly. Plus, a plugin is better for marketing.
Secondly, it seems that this will leverage (*grin*) Google's existing caching infrastructure. I don't know how well that maps to the standard proxy server model - it might not.
So you cann't use it on a plane.
The air pressure in planes is higher than the air pressure outside at high altitudes... You can use it on a plane (why would you want to).but how can we be sure that Google doesn't favor our favorite open source http server over IIS
To repeat myself: Because Google's results mirror the market share of the respective servers as determined by Netcraft.The Fine Article states that while Google's results are comparable to Netcraft's server survey results (that is, their share of Apache and IIS represents the respective market share), MSN seems to favor IIS. So no, Google does not favor Apache.
I have no idea how you set out to become the de facto standard other than getting everyone to use it.
Right. TFA about this: