This is 100% totally wrong. The GPL is unusual in fact, in that it requires this. Creation of a derived work is normally prohibited, but the BSD license allows it (almost) unconditionally. You are perfectly free to re-license BSD code under whatever terms you want and in fact this is exactly what people do when then sell closed-source software based on BSD.
The difficulty is not in the Carmacks and other geniuses managing to parellelize things, it's for the typical programmer to parellelize, especially in large scale applications. Concurency bugs are amazingly difficult to detect and debug, and highly concurrent programs require a large amount of skill and analysis if you want them to be both fast and correct. The vast majority of multithreaded applications today are *slower* (in absolute terms - again, not responsiveness, but performance) because of multithreading, not faster, and they still have deadlocks and race conditions and memory corruption. Theres almost certainly room for improvement in our tools for automatic parellelization, and room for improvement in the tools programmers use to write parellel programs, but I don't believe that typical applications will see signifigant speedups from multicore machines.
Actually, by default, you won't see much if you type sex into Google. And why are your children typing sex into Google anyway? Is it perhaps because they want to look at pictures of people having sex? It's pretty much an open question of whether or not thats harmful, and it's something you as a parent, and we as a society, will have to deal with at some point regardless. There's only so long you can just pretend it doesn't exist, especially when there are so many people so willing to show you that it does.
Your proposed law is idiotic, and I'm sure that if you think for 10 minutes about how it'd be implemented and enforced you'll realize that. By the way, if your wife feels the need to use technical means to keep you from seeing porn on the internet, then your marriage is a sham and a lie anyway.
I would stake money that Apple will shut down (via C&D, legal threats, software update, whatever) any attempt at making OS X86 run on generic hardware easy or out of the box. I doubt they'll sweat it as long as it's hard and hackerish - Jobs is aware of the limitations of DRM and I'm sure they know it'll happen. It's not worth the money and effort to try to prevent it. What they will try to prevent is any attempt to sell or otherwise provide an off the shelf solution. And I suspect they won't have too much trouble being successfull in this regard.
You cannot hide the gory details and also thread for (pure) performance, at least not to any signifigant degree, and not with our current ability to analyze programs. Some current compilers/languages can squeeze out some parallelism via analysis, but to prevent bugs they must be conservative, so you rarely get signifigant performance boosts. The key to parallelizing performance is minimizing information sharing, and thats a design/archiectural issue that can't really be addressed automatically. It's not simply a matter of higher level languages or cleverer code - the inherent complexities and dangers of multi-threaded programming are quite large, to the point where it's almost impossible to prove the correctness of any signifigantly multithreaded application while still gaining a performance boost.
Note that I am talking about pure performance gain here, not percieved performance, such as keeping a GUI responsive during long actions - that kind of MT is generally slower than the single threaded alternative, and is fairly easy to keep correct.
Gaining performance via multithreading requires you to seperate out multiple calculations, with minimal dependencies between them. The number of applications that can benefit from this is much smaller than you might think. I doubt very much that we'll see very many applications get a boost from dual/many core processers, and it's not just a matter of "re-writing legacy apps". What we will see is over all system speed increases on multi-threaded OSes.
From when I was googling for deck-shuffling algorithms, the online sites tend to (using the same boilerplate, interestingly) claim to use a "modified" version of the classic Knuth shuffle, backed by a physically-seeded RNG. Heck, random.org should work fine.
I'm not the grandparent and my atheist beliefs come from several years of Bible and theology study. So nuts to you on that one. I know all about what Christians believe, and how it conflicts with what they purport to believe, and how it's different from how they actually act. Yes, I'm very much aware that different churches have different doctrines. I was responding to a post that implied that there is no judeochristian belief against body piercing, which is untrue - there certainly is. It's not widespread in Christianity, although it's present, but it's pretty common among Jews. Which is what I said.
Go read your bible, buddy. Most Christians don't bother with the fiddly bits (this specific fiddly bit is in Leviticus), but some of the fundamentalists do. Fundamentalist/conservative Jews also don't allow body modification. Not sure about Islam.
You need a document which is either exactly the same size (if there's size checks built into verification), or close enough in size that it won't raise suspicion. Incidently, this is a major weakness in crappy bloated formats like.doc and.pdf, where people don't blink twice about a 2 page text document being 4 megs in size.
Given that restriction, you then need to be able to generate a collision. And not just any collision, but a *specific* collision that has your malware or subtle contract alterations or whatever in it. Hashing is used as verification, so simple corruption is useless.
The flaws being found are not totally irrelevent, by any means, but they're theoretical mathematical attacks on hashing. The practical security of hashing as verification is not especially weakend.
A library is *not* a library. First off, if you depend on anything except the system libraries, you're on your own. And if you use the system libraries, you must ensure that you target a specific OS release version, and you have minimal resources at hand to allow you to target previous versions. Yes, you can just package everything in your app bundle. This is a stupid wasteful solution and there's a reason people prefer dynamic libraries. Yes, XCode will allow you to check that you don't use Cocoa/UI features not present in old versions, no it doesn't work for everything. OS X deals with dependency problems by ignoring them and having the developer deal with everything. A packaging system provides tools so the user and the developler work together to solve them.
On OS X, I can't update my version of WebCore to get some of the new fixes I want. I can't do this because my applications will break. My apps will break because nobody ships apps using anything except the Apple-provided webcore. System libraries are not considered upgradable by the user. This is totally opposite to the Linux culture where upgrading is considered a normal, acceptable activity, and there are tools and methodolgies in place to assist it.
What you're describing as a "problem" in Linux is easily solved by not upgrading, which is what you want to do anyway. You don't have that problem on OS X because you don't and can't update libraries. If you didn't update stuff on your Linux installs, nothing would break either. And thats granting your "applications who's dependencies can't be automatically updated", which I have yet to find a problem. If I need to install software manually, and I care about it being tracked properly for dependencies, I'll build a package for it and install it via dpkg/rpm, so everything knows about it.
The one-third number was taken directly from Bill Allomberts ass. Note that it wasn't even "1/3rd of my machines failed", or "1/3rd of the people I know had trouble", which would still be useless, just that he guessed about a third would have trouble. Don't judge anything based on that.
It would probably be a usefull patch to apt to have it update itself (and it's dependencies) before doing a dist-upgrade or anything. Of course, you have to get people to update just apt to get the updated apt which will update itself....
As a developer, the OS X solution sucks ass. It doesn't work. And the packaging one does. So what it tells *me* is that packaging is better.
As a user, they're exactly the same except that I get to choose when I want to update from upstream instead of only getting it when Apple says it's okay (I use both a Mac and Linux - and Windows for that matter which is in a shithole no matter how you look at it). So it's either a wash, or a win for packaging, depending on how much you like to play with your system.
Hell, the second paragraph of the article does it.
More than 5 percent of scientists answering a confidential questionnaire admitted to having tossed out data because the information contradicted their previous research or said they had circumvented some human research protections.
Tossed out data OR circumvented human research protections? Those are totally different things! What the hell?!
You're just playing with definitions. Someone with Debian Woody will have the current version of GLib defined for Debian Woody, unless they either installed a different one manually, or chose not to update. There is nothing about this that is different than OS X or, indeed, any other OS out there. The package is doing exactly the correct thing, assuming the dependency information is correct and just just set arbitrarily - if the app won't run with GLib 2.1, then it won't install unless you update. If it won't run with 2.5, it won't install unless you downgrade (but you probably don't want to, you probably want a new version of the app). OS X has these *exact* same problems, some of them even worse because of just how much Apple will change system APIs around between releases.
The whole point of the packaging and dependency version is to allow regular, dynamic updating of libraries (your "solution" is, in effect, that any update is a new OS version - this is essentially what Apple does), and to provide you with tools to manage the inevitable dependency problems that will come from that. It has jack all to do with "system wide patchlevels" or anything else you're talking about.
OS X absolutely is isolated from outside developments. You won't get improvements to WebCore until there's a new OS release, unless you manage them yourself. Applications what rely on a new version of WebCore won't run, and to make matters even more fun, OS X has no way for you to easily declare this dependency, so you either handle it at runtime in your app or you write a custom installer to check for you.
If all they had to do was upgrade, the installer / updater should have done that automatically
Don't know much about Debian, do you? Anyway, that is (precisely) what these release notes told you to do. Upgrade apt, then upgrade everything else. Very simple.
Re:PHP definitely does not follow the KISS princip
on
A Decade of PHP
·
· Score: 1
You can use native drivers in CF. Or a number of different connectivity backends.
PEARs shitty pseudo-functional crappy SQL generating query engine is the worst damn way to access a database I've ever seen. I was trying to be nice in the original post.
Even if PEARs implementation wasn't utter crap, CFs model would still be superior - because it's got a consistent, easy to use and easy to model query object representing the result set. Access to this object is consistent with everything else in CF, and it's a first class datatype. Even the block markup is superior in this case, because passing 400 line SQL statements around in strings to PEARS shitty functions sucks.
This is almost totally untrue. Any legitimate company beyond a certain size will have a physical presence (an office, if you will), which is publically posted and available. A lot of very small, one or two man operations run out of someones living room will use a PO Box so that they can pretend to be a large, reliable company you'd feel more comfortable giving your money too. It's not neccesarily bad if Infineon is/was one of those, but there's nothing wrong with exposing it, either, especially when they publically claim otherwise.
Re:PHP definitely does not follow the KISS princip
on
A Decade of PHP
·
· Score: 1
Versions of CF less than 5 years old pretty much spank PHP. As soon as it got first-class UDFs, the power really expanded. CFCs are super. PHP gives you much easier access to some a lot of low-level functions (file manipulation is a pain in CF), but CFs modularity (what? There's more than just includes?) and stuff like the cfquery/DB abstraction layer is far superior to PHPs.
I'm not sure how accurate this is - I've been pretty poor before and canned veggies are one thing you could always find at a food bank or whatever - but I've never been urban poor so who knows. But it's obvious to anyone who looks, and has been for decades, that the class rift is growing.
My favorite are the random word association ones that try to defeat bayesian filtering. Some of them are fantastic, like being at a beat poetry coffee house.
birth is fed turbulent and chub not buckboard indiscreet. Sometimes exultation absurd can amherst but extrapolate are not saute.
If daze, then not here.
Is one I got a couple days ago and am keeping around as a sort of pet.
If this is what you do everytime theres a break-in at your company, I fear for your security. First off, you're presuming that he didn't delete the accounts beyond ADs ability to restore them, which is a pretty big assumption. And you're ignoring the work involved in auditing the restores of all the users data and privledges, to make sure that you don't accidently restore any tampering. Dealing with a large scale security breach is complicated and a major task, and while it's not fair to pin the total cost on the hacker (like fixing the hole he came in through), the secondary costs can be quite large - auditing and figuring out how he came in in the first place, deciding exactly how much of your infrastructure you can trust after the breakin, what a safe date to restore off tape is, etc, etc.
Interestingly, WoW features the ability to turn in heads (and other body parts) in exchange for bounties, and I understand it's quite popular in Germany.
This actually raises a good point, which is that since your typical employer tries to maintain quite a bit of control over your personal life outside of work (and the same people who come out to defend snooping also come out to defend their right to fire people for it), you'd think they WANT you to use your company email for personal usage. Makes it easier to fire you if you accidently ever say anything derogitory about your working conditions.
Of course, depending your filesystem, it's pretty likely that you won't actually save any space going from 16136 bytes to 14 bytes. And while you (might) save some disk space,/bin/true now requires a shell invocation, which is an enormous performance penalty.
The Mac is already a superior development platform to Linux in a lot of ways. Cocoa and ObjC are magnificent. XCode is awesome. (Which is not to say that there aren't great tools and libraries under Linux, just that the Mac ones are really fantastic). There's still plenty of Linux developers, because people like to develop on Free platforms, or because they just like Linux, or because (and this is a big one) Macs are really expensive, the Mini aside. Apple won't support OS X on commodity hardware and will no doubt use legal muscle to shut down attempts at it, so it'll never be widespread - so no community there. I seriously doubt Apple with ever open source the parts of OS X that make it so great to develop for, like Cocoa. I think Dvorak is (no supprise) totally offbase on this and the switch to x86, while pretty ground shaking, will have no appreciable affect on Linux development. If anything, it'll be the opposite - not that I anticipate much of that either.
Slashdot Mirror
This is 100% totally wrong. The GPL is unusual in fact, in that it requires this. Creation of a derived work is normally prohibited, but the BSD license allows it (almost) unconditionally. You are perfectly free to re-license BSD code under whatever terms you want and in fact this is exactly what people do when then sell closed-source software based on BSD.
The difficulty is not in the Carmacks and other geniuses managing to parellelize things, it's for the typical programmer to parellelize, especially in large scale applications. Concurency bugs are amazingly difficult to detect and debug, and highly concurrent programs require a large amount of skill and analysis if you want them to be both fast and correct. The vast majority of multithreaded applications today are *slower* (in absolute terms - again, not responsiveness, but performance) because of multithreading, not faster, and they still have deadlocks and race conditions and memory corruption. Theres almost certainly room for improvement in our tools for automatic parellelization, and room for improvement in the tools programmers use to write parellel programs, but I don't believe that typical applications will see signifigant speedups from multicore machines.
Your proposed law is idiotic, and I'm sure that if you think for 10 minutes about how it'd be implemented and enforced you'll realize that. By the way, if your wife feels the need to use technical means to keep you from seeing porn on the internet, then your marriage is a sham and a lie anyway.
I would stake money that Apple will shut down (via C&D, legal threats, software update, whatever) any attempt at making OS X86 run on generic hardware easy or out of the box. I doubt they'll sweat it as long as it's hard and hackerish - Jobs is aware of the limitations of DRM and I'm sure they know it'll happen. It's not worth the money and effort to try to prevent it. What they will try to prevent is any attempt to sell or otherwise provide an off the shelf solution. And I suspect they won't have too much trouble being successfull in this regard.
Note that I am talking about pure performance gain here, not percieved performance, such as keeping a GUI responsive during long actions - that kind of MT is generally slower than the single threaded alternative, and is fairly easy to keep correct.
Gaining performance via multithreading requires you to seperate out multiple calculations, with minimal dependencies between them. The number of applications that can benefit from this is much smaller than you might think. I doubt very much that we'll see very many applications get a boost from dual/many core processers, and it's not just a matter of "re-writing legacy apps". What we will see is over all system speed increases on multi-threaded OSes.
From when I was googling for deck-shuffling algorithms, the online sites tend to (using the same boilerplate, interestingly) claim to use a "modified" version of the classic Knuth shuffle, backed by a physically-seeded RNG. Heck, random.org should work fine.
I'm not the grandparent and my atheist beliefs come from several years of Bible and theology study. So nuts to you on that one. I know all about what Christians believe, and how it conflicts with what they purport to believe, and how it's different from how they actually act. Yes, I'm very much aware that different churches have different doctrines. I was responding to a post that implied that there is no judeochristian belief against body piercing, which is untrue - there certainly is. It's not widespread in Christianity, although it's present, but it's pretty common among Jews. Which is what I said.
Go read your bible, buddy. Most Christians don't bother with the fiddly bits (this specific fiddly bit is in Leviticus), but some of the fundamentalists do. Fundamentalist/conservative Jews also don't allow body modification. Not sure about Islam.
Given that restriction, you then need to be able to generate a collision. And not just any collision, but a *specific* collision that has your malware or subtle contract alterations or whatever in it. Hashing is used as verification, so simple corruption is useless.
The flaws being found are not totally irrelevent, by any means, but they're theoretical mathematical attacks on hashing. The practical security of hashing as verification is not especially weakend.
On OS X, I can't update my version of WebCore to get some of the new fixes I want. I can't do this because my applications will break. My apps will break because nobody ships apps using anything except the Apple-provided webcore. System libraries are not considered upgradable by the user. This is totally opposite to the Linux culture where upgrading is considered a normal, acceptable activity, and there are tools and methodolgies in place to assist it.
What you're describing as a "problem" in Linux is easily solved by not upgrading, which is what you want to do anyway. You don't have that problem on OS X because you don't and can't update libraries. If you didn't update stuff on your Linux installs, nothing would break either. And thats granting your "applications who's dependencies can't be automatically updated", which I have yet to find a problem. If I need to install software manually, and I care about it being tracked properly for dependencies, I'll build a package for it and install it via dpkg/rpm, so everything knows about it.
It would probably be a usefull patch to apt to have it update itself (and it's dependencies) before doing a dist-upgrade or anything. Of course, you have to get people to update just apt to get the updated apt which will update itself....
As a user, they're exactly the same except that I get to choose when I want to update from upstream instead of only getting it when Apple says it's okay (I use both a Mac and Linux - and Windows for that matter which is in a shithole no matter how you look at it). So it's either a wash, or a win for packaging, depending on how much you like to play with your system.
The whole point of the packaging and dependency version is to allow regular, dynamic updating of libraries (your "solution" is, in effect, that any update is a new OS version - this is essentially what Apple does), and to provide you with tools to manage the inevitable dependency problems that will come from that. It has jack all to do with "system wide patchlevels" or anything else you're talking about.
OS X absolutely is isolated from outside developments. You won't get improvements to WebCore until there's a new OS release, unless you manage them yourself. Applications what rely on a new version of WebCore won't run, and to make matters even more fun, OS X has no way for you to easily declare this dependency, so you either handle it at runtime in your app or you write a custom installer to check for you.
Don't know much about Debian, do you? Anyway, that is (precisely) what these release notes told you to do. Upgrade apt, then upgrade everything else. Very simple.
This is almost totally untrue. Any legitimate company beyond a certain size will have a physical presence (an office, if you will), which is publically posted and available. A lot of very small, one or two man operations run out of someones living room will use a PO Box so that they can pretend to be a large, reliable company you'd feel more comfortable giving your money too. It's not neccesarily bad if Infineon is/was one of those, but there's nothing wrong with exposing it, either, especially when they publically claim otherwise.
Versions of CF less than 5 years old pretty much spank PHP. As soon as it got first-class UDFs, the power really expanded. CFCs are super. PHP gives you much easier access to some a lot of low-level functions (file manipulation is a pain in CF), but CFs modularity (what? There's more than just includes?) and stuff like the cfquery/DB abstraction layer is far superior to PHPs.
I'm not sure how accurate this is - I've been pretty poor before and canned veggies are one thing you could always find at a food bank or whatever - but I've never been urban poor so who knows. But it's obvious to anyone who looks, and has been for decades, that the class rift is growing.
If this is what you do everytime theres a break-in at your company, I fear for your security. First off, you're presuming that he didn't delete the accounts beyond ADs ability to restore them, which is a pretty big assumption. And you're ignoring the work involved in auditing the restores of all the users data and privledges, to make sure that you don't accidently restore any tampering. Dealing with a large scale security breach is complicated and a major task, and while it's not fair to pin the total cost on the hacker (like fixing the hole he came in through), the secondary costs can be quite large - auditing and figuring out how he came in in the first place, deciding exactly how much of your infrastructure you can trust after the breakin, what a safe date to restore off tape is, etc, etc.
Interestingly, WoW features the ability to turn in heads (and other body parts) in exchange for bounties, and I understand it's quite popular in Germany.
This actually raises a good point, which is that since your typical employer tries to maintain quite a bit of control over your personal life outside of work (and the same people who come out to defend snooping also come out to defend their right to fire people for it), you'd think they WANT you to use your company email for personal usage. Makes it easier to fire you if you accidently ever say anything derogitory about your working conditions.
Of course, depending your filesystem, it's pretty likely that you won't actually save any space going from 16136 bytes to 14 bytes. And while you (might) save some disk space, /bin/true now requires a shell invocation, which is an enormous performance penalty.
The Mac is already a superior development platform to Linux in a lot of ways. Cocoa and ObjC are magnificent. XCode is awesome. (Which is not to say that there aren't great tools and libraries under Linux, just that the Mac ones are really fantastic). There's still plenty of Linux developers, because people like to develop on Free platforms, or because they just like Linux, or because (and this is a big one) Macs are really expensive, the Mini aside. Apple won't support OS X on commodity hardware and will no doubt use legal muscle to shut down attempts at it, so it'll never be widespread - so no community there. I seriously doubt Apple with ever open source the parts of OS X that make it so great to develop for, like Cocoa. I think Dvorak is (no supprise) totally offbase on this and the switch to x86, while pretty ground shaking, will have no appreciable affect on Linux development. If anything, it'll be the opposite - not that I anticipate much of that either.